## Experiment summary

We believe that... {describe your hypothesis in one sentence}

To verify that, we will... {describe your test in one sentence}

And we’ll 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 doesn’t 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 we’re 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, we’re hoping our experiment will ... but we’re 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"