42 lines
2.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## Experiment summary
We believe that... {describe your hypothesis in one sentence}
To verify that, we will... {describe your test in one sentence}
And well measure the impact on... {metrics}
## Hypothesis
<!-- The hypothesis represents the high-level thought process in creating the experiment but does not need to be proven in one experiment. For example, you could have a hypothesis that “users would benefit from more easily being able to have a one-click-sandbox” and your first experiment could fail, that doesnt void your hypothesis only indicates you may need to think of a new iterative experiment that would still align with your hypothesis. -->
## Supporting data
<!-- Why should we run this experiment? Why do you belive your Hypothesis to be true? -->
## Expected outcome
<!-- What is the expected outcome of this experiment, what metric are we trying to move? Are there any metrics we know we do not want to impact? -->
## Experiment design & implementation
<!-- What is the experiment were going to run? -->
## Known assumptions
<!-- This is an area to call out known assumptions in the experiment, this is especially helpful for any future colleagues that join the team so they understand other potential influences and how they were accounted for. This section is also helpful in framing possible scenarios and to keep the door open for the next steps. For example, were hoping our experiment will ... but were assuming .... This is a known assumption and depending on the results of the experiment could impact the direction we take on any future iterations. -->
## Results, lessons learned, next steps
<!-- What were the results of the experiment? Was the experiment a success or a failure? Based on the results should we remove the code or advocate that it become a permanent part? Are there future experiments to run based off these results (include a link to new issue)? For example, our trial experiment was successful we ... but saw .... Our next experiment (link) will focus on .... -->
## Checklist
- [ ] Fill in the experiment summary and write more about the details of the
experiment in the rest of the issue description. Some of these may be
filled in through time (the "Result, learnings, next steps" section for
example) but at least the experiment summary should be filled in right
from the start.
/label ~"workflow::validation backlog" ~"experiment idea"