<!-- Link to the failing master build and add the build failure output in the below code block section. -->
### Steps to reproduce
<!-- If the pipeline failure is reproducible, provide steps to recreate the issue locally. Please use an ordered list. -->
### Proposed Resolution
<!-- Describe the proposed change to restore master stability. -->
Please refer to the [Resolution guidance](https://about.gitlab.com/handbook/engineering/workflow/#resolution-of-broken-master) to learn more about resolution of broken master.
<!--Lightweight issue template to facilitate decision making by using Decision Matrix -->
## Problem to solve
<!--Link to Description of feature (Documentation, Epic, Opportunity Canvas, etc.) -->
## Decision Matrix
<!-- Decision Matrix helps make a decision based on the acceptance criteria defined for the problem. Acceptance criteria should be put into left column, in the order of importance, with clear information if they are required (must-have) or not (nice-to-have). Options to consider should be scored in the right-side columns. To mark option as viable, it should fulfill all required criteria. -->
Before raising an issue to the GitLab issue tracker, please read through our guide for finding help to determine the best place to post:
* https://about.gitlab.com/getting-help/
If you are experiencing an issue when using GitLab.com, your first port of call should be the Community Forum. Your issue may have already been reported there by another user. Please check:
* https://forum.gitlab.com/
If you feel that your issue can be categorized as a reproducible bug or a feature proposal, please use one of the issue templates provided and include as much information as possible.
Thank you for helping to make GitLab a better product.
<!-- template sourced from https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Default.md -->
For guidance on the overall deprecations, removals and breaking changes workflow, please visit [Breaking changes, deprecations, and removing features](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes)
<!-- Use this template as a starting point for deprecations. -->
### Deprecation Summary
<!--
This should contain a brief description of the feature or functionality that is deprecated. The description should clearly state the potential impact of the deprecation to end users.
It is recommended that you link to the documentation.
The description of the deprecation should state what actions the user should take to rectify the behavior. If the deprecation is scheduled for an upcoming release, the content should remain in the deprecations documentation page until it has been completed. For example, if a deprecation is announced in 14.9 and scheduled to be completed in 15.0, the same content would be included in the documentation for 14.9, 14.10, and 15.0.
**If this issue proposes a breaking change outside a major release XX.0, you need to get approval from your manager and request collaboration from Product Operations on communication. Be sure to follow the guidance [here](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes.)**
-->
### Breaking Change
<!-- Does this MR contain a breaking change? If yes:
- Add the ~"breaking change" label to this issue.
- Add instructions for how users can update their workflow. -->
### Affected Topology
<!--
Who is affected by this deprecation, Self-managed users, SaaS users, or both? This is especially important when nearing the annual major release where breaking changes and removals are typically introduced. These changes might be seen on GitLab.com before the official release date.
-->
### Affected Tier
<!--
Which tier is this feature available in?
* Free
* Premium
* Ultimate
-->
### Checklists
**Labels**
- [ ] This issue is labeled ~deprecation, and with the relevant `~devops::`, `~group::`, and `~Category:` labels.
-[ ] This issue is labeled ~"breaking change" if the removal of the deprecated item will be a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes).
**Timeline**
Please add links to the relevant merge requests.
- As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: `14.8, 14.9, 14.10, 15.0` – `14.8` is the third milestone preceding the major release):
-[ ] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations).
-[ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/ee/development/documentation/versions.html#deprecations-and-removals).
-[ ] On or before the major milestone: A [removal entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement-1) has been created so the removal will appear on the [removals by milestones](https://docs.gitlab.com/ee/update/removals) page and be announced in the release post.
- On the major milestone:
- [ ] The deprecated item has been removed.
-[ ] If the removal of the deprecated item is a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes), the merge request is labeled ~"breaking change".
**Mentions**
- [ ] Your stage's stable counterparts have been `@mentioned` on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager.
- To see who the stable counterparts are for a product team visit [product categories](https://about.gitlab.com/handbook/product/categories/)
- If there is no stable counterpart listed for Sales/CS please mention `@timtams`
- If there is no stable counterpart listed for Support please mention `@gitlab-com/support/managers`
- If there is no stable counterpart listed for Marketing please mention `@cfoster3`
- [ ] Your GPM has been `@mentioned` so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.
### Deprecation Milestone
<!-- In which milestone will this deprecation be announced ? -->
### Planned Removal Milestone
<!-- In which milestone will the feature or functionality be removed and announced? -->
### Links
<!--
Add links to any relevant documentation or code that will provide additional details or clarity regarding the planned change.
This issue is the main SSOT for the deprecations and removals process. Be sure to link all
issues and MRs related to this deprecation/removal to this issue. This can include removal
issues that were created ahead of time, and the MRs doing the actual deprecation/removal work.
-->
<!-- Label reminders - you should have one of each of the following labels.
Use the following resources to find the appropriate labels:
This template outlines a sample set-up process, activities and deliverables for running a Remote Design Sprint. The specific activities and deliverables should be customized based on your objectives and timeline.
Please refer to the [Remote Design Sprint Handbook page](https://about.gitlab.com/handbook/product/ux/design-sprint/) for additional recommendations.
## Design Sprint Focus
*[ ] Have you [determined that a Design Sprint is appropriate for this project](https://about.gitlab.com/handbook/product/ux/design-sprint/#when-to-opt-for-a-remote-design-sprint)?
_What is the focus of the [Design Sprint](https://about.gitlab.com/handbook/product/product-processes/#remote-design-sprint)? What problem area will you be solving for and who is the target user?_
## Objectives
_What is the objective(s) this Design Sprint will entail?_
<!-- Try to describe the objectives of the Sprint in detail. e.g., "We want to introduce a new feature but we are unsure that we are thinking about the solution from the customer's perspective, and through the Sprint we want to rethink the solution, prototype it and validate it with our customers" or "We are unhappy with the direction of one of our categories and we want to explore new directions with different stakeholders, reach to one solution and test it with users" or "Among the team we have different visions for a specific category and we want to work towards a solution we all support and test it with users". -->
## Outputs
_Select which outputs you want to have at the end of the Sprint._
- [ ] A User testing flow.
- [ ] A Prototype to be tested with users.
- [ ] User testing analysis.
- [ ] (If the solution is viable) An epic or issue that describes the direction in details and the next steps
- [ ] Necessary updates to the Handbook.
## Design Sprint Details
| Start | End |
| ------ | ------ |
| YYYY-MM-DD | YYYY-MM-DD |
| TT:TT PST | TT:TT PST |
**Reference time zone:** All times will be posted in [UTC](https://www.timeanddate.com/worldclock/timezone/utc).
### WHERE
**Zoom link:**
### WHO
-`Name``gitlab handle` - Facilitator
-`Name``gitlab handle` - Decider (usually the Product Manager)
Here is the list of tools for the Sprint preparation, collaboration and documentation. Prior to the Sprint make sure you have access to all of the following:
***GitLab**<br/>
Each Sprint day outcomes and material will be documented in separate issues under the Design Sprint epic:
***Kickoff:** (Kickoff Issue Link)
***Day One:** (Day 1 Issue Link)
***Day Two:** (Day 2 Issue Link)
***Day Three:** (Day 3 Issue Link)
***Day Four:** (Day 4 Issue Link)
***Mural** (You can join as anonymous but we need to be able to identify input against names, so please create an account beforehand.)<br/>
We will use Mural for most of the Sprint collaboration. Some of the things we will do in Mural:
* Create artifacts like affinity diagrams from participants' input.
* Use post-its to comment on each other's points and to add notes.
* Vote on ideas and solutions.
* Create the first draft of the prototype.
***The Mural link can be found here:** (Mural Link)
***Video and/or screen recording tool** (Loom, Quicktime, Zoom or another tool you are using).<br/>
As part of the pre-Sprint homework, you will be asked to record a short Lightning Walkthrough video (don't worry, this will be explained in detail during the Sprint :smile:). You can use any tool you feel comfortable with as long as it can capture your screen, mouse pointer, and audio.
***A4/Letter-sized paper (preferably white, blank), Sharpies/Pens** (Please don't use a pencil because it doesn't create enough contrast for photos).<br/>
Day 2 of the Sprint involves some (async) ideation via sketching so you will need a writing utensil (Sharpies are preferred because they force you to draw at a lower fidelity because the small details aren't necessary at this point) and some paper. This is the most fun part of the Sprint where you get into a design thinking mindset and can appeal to your creative self. Don't worry, it's not about artistry, it's about ideas and collaboration. It'll be fun!
***Camera (phone or other) or scanner**<br/>
You will need to upload sketches as images for the facilitator to prepare the material before the next sync meeting. You can take a photo with your phone or use a scanner if available.
***Post-it notes (Optional)**<br/>
If you enjoy taking notes using Post-it notes make sure you have some of them as well. The upside is that they will make you feel more like you are in a workshop and will help the ideas flow (I find that typing is distracting while ideating). The downside is that you will have to digitize the ones you want to share with the team in Mural.
## Artefacts & Pre-Read Material
<!-- If there is material that will be useful for the participants to read before the Design Sprint add here, such as the sprint slide deck or design sprint material -->
### Handbook pages
<!-- Add a link to the category vision from the handbook -->
### Competitor resources
<!-- Add any solutions by competitors that are relevant to the Design Sprint topic and could be used as a source of inspiration. -->
### Articles on Design Sprints
*[The Design Sprint](https://www.gv.com/sprint/)
*[The Ultimate Guide To Remote Design Sprints](https://drive.google.com/file/d/16bwrAqHVf8qxovd87Q7LdzqwAgy7a6Rx/view?usp=sharing)
## Personas
Deciding which persona we are focusing on will be part of the Day 1 discussions in the workshop. The personas we are going to consider are:
<!-- Choose which personas could be target users, and choose from this list during the Sprint. Personas are described at https://handbook.gitlab.com/handbook/product/personas/
- [ ] Organize and inform team members who will be providing lightning talk recordings.
- [ ] Open a recruitment issue for user testing.
- [ ] Create sync meetings in calendars for all participants.
- [ ] Record Kickoff Video.
- [ ] Do a Sprint test run.
## Sprint Kickoff | `Add Date`
#### Pre-Day Facilitator Checklist:
-[ ] Ensure [Kickoff Issue](Add Link) is complete.
-[ ] Assign participants to the [Kickoff Issue](Add Link).
- [ ] Ensure warm-up exercise Mural is set up.
- [ ] Prep Q&A issue thread.
- [ ] Send a `Welcome to the Sprint` slack message.
| Activity | Type of Activity | Duration | Tool | Description |
|---|---|---|---|---|
| Introduction to Design Sprints | Async | 20 Minutes | Video Recording | • The facilitator gives an overview of the Sprint, including details about what they are, why they are used, and why they can help solve the problem for this Sprint. <br/> • The facilitator gives participants an overview of what they need to complete a Design Sprint such as a run down of the rules, and supples, as well as an agenda and basic expectations. <br/> • The facilitator gives participants an overview of the problem we will be solving and allows for an async Q&A period. |
| Icebreaker | Async | 5 Minutes | Mural | • All Sprint participants give an async introduction in Mural. |
| Q&A Period | Async | 5 Minutes | GitLab and Slack | • Participants can ask questions about the Sprint. (Optional) |
| Record Lightning Talk | Async | 10 Minutes | Zoom | • Participants record their Lightning Talk. |
#### Post-Day Facilitator Checklist:
- [ ] Answer any questions that come up during the Q&A period.
- [ ] Send a homework reminder in the Slack channel.
## Day 1 - Sprint Homework | `Add Date`
#### Pre-Day Facilitator Checklist:
-[ ] Ensure [Day 1 Issue](Add Link) is complete.
-[ ] Ensure Lightning Talk recordings are added to the [Day 1 Issue](Add Link).
- [ ] Ensure participants have access to the Note Taking Activity Walkthrough Video.
- [ ] Ensure HMW section on Mural is organized.
- [ ] Ensure participants have access to the HMW Activity Walkthrough video.
| Activity | Type of Activity | Duration | Tool | Description |
|---|---|---|---|---|
| Watch Lightning Talks | Async | 15 Minutes Per Talk | Video Recording and Note Taking Tool | • Participants will watch lightning talks and complete the note-taking activity async. <br/> • The Facilitator will provide an overview video of what is expected during the note taking portion of this activity. |
| How Might We’s (HMWs) | Async | 20 Minutes | Mural | • Participants will take their notes from the Lightning Talk activity and craft some HMWs around the opportunities uncovered. <br/> • The facilitator will provide participants a video to describe the HMW activity and review what makes a good HMW statement. <br/> • The facilitator will also be available to sync on Slack for any questions around the activity. |
#### Post-Day Facilitator Checklist:
- [ ] Answer any questions that come up during the async HMW activity.
- [ ] Send a sync session reminder in the Slack channel.
## Day 1 - Sync Session | `Add Date`
#### Pre-Day Facilitator Checklist:
- [ ] Ensure all sync Mural boards are organized (Affinity Mapping, Goals, Hurdles, Squiggle Birds).
- [ ] Ensure sync session is recorded.
| Activity | Type of Activity | Duration | Tool | Description |
|---|---|---|---|---|
| Affinity Mapping | Sync | 30 Minutes | Zoom and Mural | • Participants take turns reading aloud their HMWs. (5 minutes). <br/> • Once the review has completed, the facilitator will choose an Affinity Mapper who will be in charge of categorizing the HMWs with the help of the entire group (10 Minutes). <br/> • Once the HMWs are organized into categories, the group will do a round of dot voting on the categories we want to focus on for the Sprint. Each participant will get three votes, and vote individually on the category they feel is most important to work on (10 Minutes). <br/> • The facilitator will allow time for discussion around the HMW groups chosen, and see if there needs to be adjustments (5 Minutes). |
| Sprint Goal | Sync | 20 Minutes | Zoom and Mural | • Based on the outcomes of the HMW activity, participants start by asking themselves the following question: “If everything worked out perfectly, what would that look like for this project?” <br/> • Each participant writes one Sprint goal on a Mural sticky starting with “By the end of the Sprint…” (10 Minutes) <br/> • Everyone on the team should share their Sprint Goal with the larger group and post them on the Mural (5 Minutes). <br/> • Everyone is given one dot to vote on what they think the Sprint Goal should be. (5 Minutes) |
| Sprint Hurdles | Sync | 20 Minutes | Zoom and Mural | • Participants will list out possible critical hurdles, in the form of a question, that may stop you from reaching your goal: What could stop us or heavily impact us from reaching our goals? <br/> • Each question must start with ‘Can we...’ <br/> • Each person can only write 2 questions (10 Minutes) <br/> • Everyone on the team should share their Hurdles back to the larger group and post them up on the Mural (5 Minutes). <br/> • Everyone is given three to vote on what they think are the most important to focus on as challenges toward the Goal. (5 Minutes) |
| Recap of Day | Sync | 5 Minutes | Zoom and Mural | • Facilitator gives and overview of what has been completed so far during Day 1 of the Sprint and expectations for Day 2 Homework |
| Squiggle Birds | Sync | 5 Minutes | Zoom, Paper and Pen/Sharpie | • Sync warm-up drawing activity to prep for next async tasks. <br/> • The facilitator will draw a squiggle on Mural and encourage all participants to also make a squiggle. <br/> • Everyone will then turn the squiggle into a bird. <br/> • The facilitator will share that "Our minds are great at recognizing patterns." Sketches are only used to convey an idea, so they don't need to be super detailed or accurate. |
#### Post-Day Facilitator Checklist:
- [ ] Send a Day 1 overview and homework reminder in the Slack channel.
- [ ] Post-sync session recording in the Slack channel.
-[ ] Ensure [Day 2 Issue](Add Link) is complete.
- [ ] Ensure participants have access to the Crazy 8s Walkthrough Video.
- [ ] Ensure the Crazy 8s section on Mural is organized.
## Day 2 - Sprint Homework | (Add Date)
#### Pre-Day Facilitator Checklist:
-[ ] Ensure Ideation recordings are added to the [Day 2 Issue](Add Link).
- [ ] Ensure participants have access to the Ideation Walkthrough Videos.
- [ ] Ensure the Ideation section on Mural is organized.
| Activity | Type of Activity | Duration | Tool | Description |
|---|---|---|---|---|
| Note Recap | Async | Google Docs | 5 Minutes | • Review all the notes that were taken during Day 1. <br/> • Review all the HMW stickies to jog your memory. |
| Ideas List | Async | Google Docs | 5 Minutes | • On a piece of paper jot down any solutions that come to mind around solving HMW statements. |
| Crazy 8s | Async | Paper and Marker/Pen | 8 Minutes | • Grab your printer paper and create an 8-panel page by folding your paper in half 3 times. <br/> • Draw a sketch for an idea in each rectangle. <br/> • Start at the top of your HMW statements/ideas list from the previous activity.|
| Share-out Prep | Async | Mural | 10 Minutes | • In preparation for the share-out, take a photo of your Crazy 8 paper and add it to the Mural. |
#### Post-Day Facilitator Checklist:
- [ ] Send a sync session reminder in the Slack channel.
| Activity | Type of Activity | Duration | Tool | Description |
|---|---|---|---|---|
| Crazy 8's Share out and Voting | Sync | 15 Minutes | Zoom and Mural | • Each person will have two minutes to present their ideas to the team. <br/> • After each team member has gotten the chance to present their ideas, we will do a round of dot voting. <br/> • Vote on the ideas you think will be best to solve our Sprint problem. <br/> • Each team member will get 3 votes. |
| Storyboarding Key Moments | Sync - 2 Groups | 30 Minutes | Zoom, Paper and Sharpie/Pen | • Take the first 10 minutes to write down the 8-10 key moments individually. <br/> • As a team decide on the ideal storyboard together. <br/> • Try and bring out the task that needs to be done and the emotion that you would like the user to experience. <br/> • No drawing yet! |
| Storyboard Details | Sync | 20 Minutes | Zoom, Paper and Pen/Sharpie | • Take your draft storyboard and give it more detail. <br/> • DRAW BIG! Sketch 1 key moment per 8.5x11 page. <br/> • Each person on the team should sketch at least 1 key moment. <br/> • Focus on actions and emotions. |
| Put Together the Story | Sync | 10 Minutes | Zoom and Mural | • Each person will take a photo of their storyboard and add it to the Mural. |
| Storyboard Share Out and Voting | Sync | 15 Minutes | Zoom and Mural | • Each group takes turns presenting their story to the Sprint team. <br/> • Once both teams have had the chance to present their storyboard, we’ll hold a round of voting. <br/> • Each person will be given 3 votes to vote for any part of each experience they like. <br/> • The Decider gets 6 votes for this activity, 3 mega-likes and 3 dislikes. |
| All in One or Rumble | Sync | 5 Minutes | Zoom | • Decide as a group if you want to incorporate the best parts of both storyboards into one or if you want to test both storyboards against each other during the testing phase. |
#### Post-Day Facilitator Checklist:
- [ ] Send a Day 2 overview and homework reminder in the Slack channel.
- [ ] Post-sync session recording in the Slack channel.
-[ ] Ensure [Day 3 Issue](Add Link) is complete.
## Day 3 - Group Sprint Homework | (Add Date)
#### Post-Day Facilitator Checklist:
- [ ] Set up a Figma File for the prototype and ensure it's shared with the group.
| Activity | Type of Activity | Duration | Tool | Description |
|---|---|---|---|---|
| Prototyping | Async | 1 Hour | Figma | • The Designer will craft out a prototype based on the storyboard for the team to review. |
| Prototyping Feedback | Async | 10 Minutes | Figma | • Once the Designer has completed the prototype, the team will review it and leave feedback. <br/> • There will only be a single round of feedback before hallway testing (where we will receive additional feedback from users). |
| Review Hallway Testing Slides | Async | 10 Minutes | Slides | • Review the details on what Hallway Testing is to prepare for the next sync session. |
#### Post-Day Facilitator Checklist:
- [ ] Send a sync session reminder in the Slack channel.
- [ ] Ensure the prototype is done and has been adjusted from the feedback.
- [ ] Gathered a few potential Hallway Test Volunteers.
| Activity | Type of Activity | Duration | Tool | Description |
|---|---|---|---|---|
| Define a Research Objective | Sync | 10 Minutes | Zoom and Mural | • As a group, write a research objective for your hallway test. Make sure to capture: What you want to learn, Who you want to talk to, What you plan to do with what you learn. |
| Write a Test Scenario | Sync | 10 Minutes | Zoom and Mural | • As a group, write a test scenario for your hallway test. <br/> • Write down a list of key tasks that you’d like the participant to complete while using the prototype. |
| Write Test Questions | Sync | 10 Minutes | Zoom and Mural | • As a group, write a test scenario for your hallway test. <br/> • Craft a list of questions and / or tasks that you’ll ask participants to answer or complete in order to answer your research objectives. |
| Hallway Testing | Sync | 50 Minutes | Zoom | • Working in groups of 2-3, review the discussion guide and prototype. <br/> • Determine who will ask questions and who will take notes. Remember to switch roles after each test! <br/> • It’s up to you where you take notes. <br/> • Join the Zoom meeting with your assigned person & test your prototype. <br/> • Have the team document what they hear and be prepared to share back with the larger sprint team. |
| Hallway Testing Share-out | Sync | 20 Minutes | Zoom | • Each group will have roughly 5 minutes to present their findings from Hallway Testing. Each team should present: <br/> • What were the common themes? <br/> • What did you hear that was surprising? <br/> • Any red flags? <br/> • Thank participants for their time. |
#### Post-Day Facilitator Checklist:
-[ ] Summarize themes of Hallway Testing and share with the Slack channel and the [Day 3 Issue](Add Link).
- [ ] Optionally, share with UX, Product, and other relevant Slack channels.
- [ ] Share with team next steps related to Day 4 and Usertesting.
## Day 4 - Usertesting | (Add Date)
<!-- Day 4 can happen at a later date when it makes the most sense. Use the problem validation issue template for Day 4. -->
Day 4 consists of a round of user testing which typically happens a week or more after the first three days complete.
***Day Four Issue:** (Day 4 Issue Link)
## Ground Rules
* Honor the Facilitator's directions. They're the guide for the entire process.
* Minimise distractions: During the week you will need to dedicate some hours to the Sprint for async tasks and sync video conferences. During this time we recommend blocking time in your calendar and having devices or apps with notifications turned off during that time.
* All opinions are valid and are equally important, however, the Decider has the ultimate, final decision.
* Everyone is an active participant in a sync activity (with the exception of the Observers).
* One conversation at a time.
* Document as much as you can: We should have concrete outputs to share with broader team. Also interesting ideas or fixes should be documented to be transferred in issues for our backlog.
* Stick to scheduled breaks during sync calls. The Facilitator will guide each session and set break times.
* The Sprint is one of the few chances we get to work so closely together. Have fun!
<!--Link to Description of feature (Documentation, Epic, Opportunity Canvas, etc.) -->
## Goals
<!--Level of Dogfooding you are looking for: problem validation, testing, production usage, etc -->
## Progress Tracker
<!--List of tasks (e.g. a table with columns, project, status, issue links similar to what is [done here](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/8499))-->
<!-- Before implementing a new empty state solution, make sure to read the
Empty State region docs in Pajamas: https://design.gitlab.com/regions/empty-states -->
## Description
<!-- Describe the solution you're proposing for your empty state region.
Include links to user research (if applicable). -->
## Location
<!-- Provide a link and location of the new empty state solution.
For example: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues -->
## Use case
<!-- What is the use case for the solution you're proposing?
Read the Empty State docs and select the use case below: https://design.gitlab.com/regions/empty-states -->
- [ ] Blank content
- [ ] Empty search results
- [ ] Configuration required
- [ ] Higher tier
## Checklist
<!-- Follow the steps below that correspond with the use case selected above.
Follow the steps to complete this issue -->
### Blank content
-[ ] The solution follows the `Blank content` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#blank-content).
-[ ] Follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
### Empty search results
-[ ] The solution follows the `Empty search results` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#empty-search-results).
-[ ] Follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
### Configuration required
-[ ] The solution follows the `Configuration required` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#configuration-required).
-[ ] Ask a [Growth product manager or Designer](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to review your solution.
- [ ] Is your solution introducing a new empty states or modifying an existing one?
-[ ] Introducing a new empty state: Follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
-[ ] Modifying an existing empty state: Follow the [`Experimentation` process](#experimentation) below. _Note_: If the empty state you want to replace hasn't been updated in a long time, doesn't pitch the value of the feature, or does not contain a next step action CTA, then we recommend you skip the experimentation process to implement and add tracking to your new empty state.
<!-- IF experimentation -->
#### Experimentation
-[ ] Collaborate with a [Growth product manager](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to help you determine if you can validate your solution through an experiment on SaaS.
-[ ] If an experiment is possible, create an issue using the [experiment idea template](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Experiment%20Idea) and follow the template intructions. Otherwise, follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
-[ ] Ask a [Growth product manager or Designer](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to review your experiment set-up.
-[ ] Implement and monitor the experiment following the [implementation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/experiment_guide/gitlab_experiment.md#implement-an-experiment).
- [ ] Review and discuss the findings.
-[ ] Add the findings to the [Growth experimentation knowledge](https://about.gitlab.com/direction/growth/#growth-experiments-knowledge-base---concluded-experiments).
### Higher tier
-[ ] The solution follows the `Higher tier` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#higher-tier).
-[ ] Ask a Product Manager or Designer from the [Conversion group](https://about.gitlab.com/handbook/engineering/development/growth/conversion/#group-members) to review your solution.
- [ ] Is your solution introducing a new empty states or modifying an existing one?
-[ ] Introducing a new empty state: follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
-[ ] Modifying an existing empty state, follow the [`Experimentation` process](#experimentation) below.
<!-- IF experimentation -->
#### Experimentation
-[ ] Collaborate with a [Growth product manager](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to help you determine if you can validate your solution through an experiment on SaaS.
-[ ] If an experiment is possible, create an issue using the [experiment idea template](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Experiment%20Idea) and follow the template intructions. Otherwise, follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
- [ ] Add a ~"Category:Conversion Experiment" label to the experiment idea issue.
-[ ] Ask a Product Manager or Designer from the [Conversion group](https://about.gitlab.com/handbook/engineering/development/growth/conversion/#group-members) to review your experiment set-up.
-[ ] Implement and monitor the experiment following the [implementation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/experiment_guide/gitlab_experiment.md#implement-an-experiment) .
- [ ] Review and discuss the findings.
-[ ] Add the findings to the [Growth experimentation knowledge](https://about.gitlab.com/direction/growth/#growth-experiments-knowledge-base---concluded-experiments).
## After merge
-[ ] Use the `Snowplow event tracking` [issue template](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Snowplow%20event%20tracking) and open an issue to add Snowplow event tracking to your new empty state solution.
- [ ] Add your ~devops:: and ~group:: labels to the new issue.
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 start a trial” 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. -->
## Business problem
<!-- Where the hypothesis is focused on the user/customer, the business problem represents why/how an experiment in this area could positively impact the business. For example, trials represent a significant way for GitLab to produce valuable leads for the sales team. -->
## Supporting data
<!-- Why should we run this experiment? What’s the potential impact? Show supporting data that’s both qualitative and quantitative. Quantitative example, we generate 30,000 sign ups a month and 900 trails within 90 days (3%) with a close rate of 10% and an IACV of $400. If we’re able to increase our trial volume by 10% percent (990 trials a month) we will generate an additional $3,600 IACV if our close rates remain constant. Qualitative example, in searching Zendesk I was able to find 10 support tickets in the last 30 days that referenced difficulties with starting a trial due to the user not being an admin. (all numbers are hypothetical and only listed for the purpose of having an example) -->
## 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? For example, we want to impact IACV by increasing the rate at which users start trials within 30 days but we also want to ensure we don't increase the churn rate for users who've recently purchased. -->
## Experiment design & implementation
<!-- What is the experiment we’re going to run? How long do you believe it will need to run to reach significance? For example, our experiment would be to allow non-admins to request a trial through their admin, to detect a 10% change from our baseline conversion rate we’ll need a sample size of 57,000 (source Optimizely), with our current sign up rate of 30,000 a month this experiment will need to run for ~2 months. (all numbers are hypothetical and only listed for the purpose of having an example) -->
## ICE score
<!-- See https://about.gitlab.com/handbook/product/growth/#growth-ideation-and-prioritization -->
| Impact | Confidence | Ease | Score |
| ------ | ------ | ------ | ------ |
| value 1 | value 2 | value 3 | Average(1:3) |
## 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 increase the number of people that start a trial but we’re assuming the conversion rate to paid and IACV will remain the same. 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 of the experience for all users? Are there future experiments the team is going to run based off these results (include a link to new issue)? For example, our trial experiment was successful we increased the trial create rate by 10% but we saw a 1% drop in our close rate which means our net impact on IACV was negative $360 (990 * 0.09 * 400 compared tot he control of 900 * 0.1 * 400). Our next experiment (link) will focus on increasing the value once a user starts a trial. (all numbers are hypothetical and only listed for the purpose of having an example) -->
## 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.
* [ ] Add the label of the `group::` that will work on this experiment (if known).
* [ ] Mention the Product Manager, Engineering Manager, and at least one Product Designer from the group that owns the part of the product that the experiment will affect.
*[ ] Fill in the values in the [ICE score table](#ice-score) ping other team members for the values you aren’t confident about (i.e. engineering should almost always fill out the ease section). Add the ~"ICE Score Needed" label to indicate that the score is incomplete.
* [ ] Replace the ~"ICE Score Needed" with an ICE low/medium/high score label once all values in the ICE table have been added.
* [ ] Mention the [at]gitlab-core-team team and ask for their feedback.
<!-- Title suggestion: Experiment Implementation: [description] -->
# Experiment Summary
<!-- Quick rundown of what is being done or a link to the Experiment epic -->
# Design
<!-- This should include the contexts that determine the reproducibility (stickiness) of an experiment. This means that if you want the same behavior for a user, the context would be user, or if you want all users when viewing a specific project, the context would be the project being viewed, etc. -->
# Control vs Candidate Experience
<!-- This should include a screenshot of the control vs candidate experience and any helpful context regarding expected behavior -->
| Control | Candidate |
|---------|-----------|
| | |
# Rollout strategy
<!-- This should outline the rollout percentages for variants and if there's more than one step to this, each of those steps and the timing for those steps (e.g. 30 days after initial rollout). -->
# Target Population
<!-- These would be the rules for which given context (and are limited to context or resolvable at experiment time details) is included or excluded from the test. An example of this would be to only run an experiment on groups who go through the Trial registration flow. -->
# Tracking Details
-[json schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/1-0-3) used in `gitlab-experiment` tracking.
- Due to data tooling limitations, we should only utilize category, action and label.
i.e. try to keep from using property and value. Be aware if adding the experiment context to existing events that
use property or value that some concessions will need to be made in order for it to show up in the experiment dashboard.
<!-- Title suggestion: [Experiment Rollout] feature-flag-name - description of experiment -->
## Summary
This issue tracks the rollout and status of an experiment through to removal.
1. Feature flag name: `<feature-flag-name>`
1. Epic or issue link: `<issue or epic link>`
This is an experiment rollout issue
using the scoped [experiment label](https://about.gitlab.com/handbook/engineering/development/growth/experimentation/#experiment-rollout-issue).
As well as defining the experiment rollout and cleanup, this issue incorporates the relevant
[`Feature Flag Roll Out`](https://gitlab.com/gitlab-org/gitlab/-/edit/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md) steps.
## Owners
- Team: `group::TEAM_NAME`
- Most appropriate slack channel to reach out to: `#g_TEAM_NAME`
- Best individual to reach out to: NAME
- Product manager (PM): NAME
### Stakeholders
<!--
Are there any other stages or teams involved that need to be kept in the loop?
- PM: Name
- Group: `group::TEAM_NAME`
- The Support Team
- The Delivery Team
-->
## Expectations
### What are we expecting to happen?
<!-- Describe the expected outcome when rolling out this experiment. -->
### What might happen if this goes wrong?
<!-- Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? -->
### What can we monitor to detect problems with this?
<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
## Tracked data
<!-- brief description or link to issue or Sisense dashboard -->
Note: you can use the [CXL calculator](https://cxl.com/ab-test-calculator/) to determine if your experiment has reached significance. The calculator includes an estimate for how much longer an experiment must run for before reaching significance.
## Rollout plan
<!-- Add an overview and method for modifying the feature flag -->
- Runtime in days, or until we expect to reach statistical significance: `30`
- We will roll this out behind a feature flag and expose this to `<rollout-percentage>`% of actors to start then ramp it up from there.
`/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
### Status
#### Preferred workflow
The issue should be assigned to the Product manager (PM) or Engineer (Eng) as follows:
1. PM determines and manages the status of the experiment (assign this issue to the PM)
1. PM asks for initial rollout on production, or changes to the status (assign to an Eng)
1. Eng changes the status using `chatops` (reassign to the PM)
1. When concluded, PM updates the 'Roll Out Steps' and adds a milestone (assigns to an Eng)
The current status and history can be viewed using the:
-[API](https://gitlab.com/api/v4/experiments)(GitLab team members)
-[Feature flag log](https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/-/issues?scope=all&utf8=%E2%9C%93&state=all)(GitLab team members)
In this rollout issue, ensure the scoped `experiment::` label is kept accurate.
### Experiment Results
<!-- update when experiment in/validated, set the scoped `~experiment::` status accordingly -->
## Roll Out Steps
-[ ] [Confirm that end-to-end tests pass with the feature flag enabled](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/feature_flags.html#confirming-that-end-to-end-tests-pass-with-a-feature-flag-enabled). If there are failing tests, contact the relevant [stable counterpart in the Quality department](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors) to collaborate in updating the tests or confirming that the failing tests are not caused by the changes behind the enabled feature flag.
- See [`#qa-staging` Slack channel](https://gitlab.enterprise.slack.com/archives/CBS3YKMGD) and look for the following messages:
- test kicked off: `Feature flag <feature-flag-name> has been set to true on **gstg**`
- test result: `This pipeline was triggered due to toggling of <feature-flag-name> feature flag`
- [ ] Enable on staging (`/chatops run feature set <feature-flag-name> true --staging`)
- [ ] Test on staging
- [ ] Ensure that documentation has been updated
- [ ] Enable on GitLab.com for individual groups/projects listed above and verify behaviour (`/chatops run feature set --project=gitlab-org/gitlab <feature-flag-name> true`)
- [ ] Coordinate a time to enable the flag with the SRE oncall and release managers
- In `#production` mention `@sre-oncall` and `@release-managers`. Once an SRE on call and Release Manager on call confirm, you can proceed with the rollout
- [ ] Announce on the issue an estimated time this will be enabled on GitLab.com
- [ ] Enable on GitLab.com by running chatops command in `#production` (`/chatops run feature set <feature-flag-name> true`)
-[ ] Cross post chatops Slack command to `#support_gitlab-com` ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#where-to-run-commands)) and in your team channel
- [ ] Announce on the issue that the flag has been enabled
-[ ] Remove experiment code and feature flag and add changelog entry - a separate [cleanup issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Experiment%20Successful%20Cleanup) might be required
-[ ] After the flag removal is deployed, [clean up the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
-[ ] Assign to the product manager to update the [knowledge base](https://about.gitlab.com/direction/growth/#growth-insights-knowledge-base)(if applicable)
## Rollback Steps
- [ ] This feature can be disabled by running the following Chatops command:
```
/chatops run feature set <feature-flag-name> false
```
## Experiment Successful Cleanup Concerns
_Items to be considered if candidate experience is to become a permanent part of GitLab_
<!--
Add a list of items raised during MR review or otherwise that may need further thought/consideration
<!-- Title suggestion: [Experiment Name] Successful Cleanup -->
## Summary
The experiment is currently rolled out to 100% of users and has been deemed a success.
The changes need to become an official part of the product.
## Steps
- [ ] Determine whether the feature should apply to SaaS and/or self-managed
- [ ] Determine whether the feature should apply to EE - and which tiers - and/or Core
- [ ] Determine if tracking should be kept as is, removed, or modified.
- [ ] Determine if any UX experiences need to be "polished" i.e. updated to further improve the end user experience. This task should be completed by the designated UX counterpart.
- [ ] (placeholder for UX polish work that needs to be completed for this cleanup issue to be considered completed)
- [ ] Ensure any relevant documentation has been updated.
- [ ] Determine whether there are other concerns that need to be considered before removing the feature flag.
- These are typically captured in the `Experiment Successful Cleanup Concerns` section of the rollout issue.
- [ ] Consider changes to any `feature_category:` introduced by the experiment if ownership is changing (PM for Growth and PM for the new category as DRIs)
- [ ] Check to see if the experiment introduced new design assets. Add them to the appropriate repos and document them if needed.
-[ ] Optional: Migrate experiment to a default enabled [feature flag](https://docs.gitlab.com/ee/development/feature_flags) for one milestone and add a changelog. Converting to a feature flag can be skipped at the ICs discretion if risk is deemed low with consideration to both SaaS and (if applicable) self managed
-[ ] In the next milestone, [remove the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) if applicable
-[ ] After the flag removal is deployed, [clean up the feature/experiment feature flags](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
-[ ] Ensure the corresponding [Experiment Rollout](https://gitlab.com/groups/gitlab-org/-/boards/1352542?label_name[]=devops%3A%3Agrowth&label_name[]=growth%20experiment&label_name[]=experiment-rollout) issue is updated
<!-- Title suggestion: [Feature flag] Cleanup <feature-flag-name> -->
## Summary
This issue is to cleanup the `<feature-flag-name>` feature flag, after the feature flag has been enabled by default for an appropriate amount of time in production.
<!-- Short description of what the feature is about and link to relevant other issues. Ensure to note if the feature will be removed completely or will be productized-->
## Owners
- Team: NAME_OF_TEAM
- Most appropriate slack channel to reach out to: `#g_TEAM_NAME`
- Best individual to reach out to: NAME
- PM: NAME
## Stakeholders
<!--
Are there any other stages or teams involved that need to be kept in the loop?
- Name of a PM
- The Support Team
- The Delivery Team
-->
## Expectations
### What might happen if this goes wrong?
<!-- Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? -->
### Cleaning up the feature flag
<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
- [ ] Specify in the issue description if this feature will be removed completely or will be productized as part of the Feature Flag cleanup
- [ ] Create a merge request to remove `<feature-flag-name>` feature flag. Ask for review and merge it.
- [ ] Remove all references to the feature flag from the codebase.
- [ ] Remove the YAML definitions for the feature from the repository.
- [ ] Ensure that the cleanup MR has been deployed to both production and canary.
If the merge request was deployed before [the code cutoff](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
the feature can be officially announced in a release blog post.
- [ ] `/chatops run auto_deploy status <merge-commit-of-cleanup-mr>`
-[ ] Close [the feature issue](ISSUE LINK) to indicate the feature will be released in the current milestone.
- [ ] If not already done, clean up the feature flag from all environments by running these chatops command in `#production` channel: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
<!-- Title suggestion: [Feature flag] Enable <feature-flag-name> -->
## Summary
This issue is to roll out [the feature](<feature-issue-link>) on production,
that is currently behind the `<feature-flag-name>` feature flag.
## Owners
- Most appropriate Slack channel to reach out to: `#<slack-channel-of-dri-team>`
- Best individual to reach out to: @<gitlab-username-of-dri>
## Expectations
### What are we expecting to happen?
<!-- Describe the expected outcome when rolling out this feature -->
### What can go wrong and how would we detect it?
<!-- Data loss, broken pages, stability/availability impact? -->
<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
## Rollout Steps
Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command.
### Rollout on non-production environments
- Verify the MR with the feature flag is merged to `master` and have been deployed to non-production environments with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
<!-- Delete Incremental roll out if it is not relevant to this deploy -->
- [ ] Deploy the feature flag at a percentage (recommended percentage: 50%) with `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors --dev --pre --staging --staging-ref`
- [ ] Monitor that the error rates did not increase (repeat with a different percentage as necessary).
<!-- End of block for deletes -->
- [ ] Enable the feature globally on non-production environments with `/chatops run feature set <feature-flag-name> true --dev --pre --staging --staging-ref`
- [ ] Verify that the feature works as expected.
The best environment to validate the feature in is [`staging-canary`](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#staging-canary)
as this is the first environment deployed to. Make sure you are [configured to use canary](https://next.gitlab.com/).
-[ ] If the feature flag causes end-to-end tests to fail, disable the feature flag on staging to avoid blocking [deployments](https://about.gitlab.com/handbook/engineering/deployments-and-releases/deployments/).
- See [`#qa-staging` Slack channel](https://gitlab.enterprise.slack.com/archives/CBS3YKMGD) and look for the following messages:
- test kicked off: `Feature flag <feature-flag-name> has been set to true on **gstg**`
- test result: `This pipeline was triggered due to toggling of <feature-flag-name> feature flag`
For assistance with end-to-end test failures, please reach out via the [`#test-platform` Slack channel](https://gitlab.slack.com/archives/C3JJET4Q6). Note that end-to-end test failures on `staging-ref`[don't block deployments](https://about.gitlab.com/handbook/engineering/infrastructure/environments/staging-ref/#how-to-use-staging-ref).
### Specific rollout on production
For visibility, all `/chatops` commands that target production should be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
and cross-posted (with the command results) to the responsible team's Slack channel.
- Ensure that the feature MRs have been deployed to both production and canary with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
-[ ] Depending on the [type of actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors) you are using, pick one of these options:
- For **project-actor**: `/chatops run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss,gitlab-com/www-gitlab-com <feature-flag-name> true`
- For **group-actor**: `/chatops run feature set --group=gitlab-org,gitlab-com <feature-flag-name> true`
- For **user-actor**: `/chatops run feature set --user=<gitlab-username-of-dri> <feature-flag-name> true`
- [ ] Verify that the feature works for the specific actors.
### Preparation before global rollout
- [ ] Set a milestone to this rollout issue to signal for enabling and removing the feature flag when it is stable.
- [ ] Check if the feature flag change needs to be accompanied with a
- [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production.
If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the `@sre-oncall` Slack alias.
-[ ] Ensure that documentation exists for the feature, and the [version history text](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#add-version-history-text) has been updated.
-[ ] Leave a comment on [the feature issue](<feature-issue-link>) announcing estimated time when this feature flag will be enabled on GitLab.com.
-[ ] Ensure that any breaking changes have been announced following the [release post process](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes) to ensure GitLab customers are aware.
-[ ] Notify the [`#support_gitlab-com` Slack channel](https://gitlab.slack.com/archives/C4XFU81LG) and your team channel ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)).
- [ ] Ensure that the feature flag rollout plan is reviewed by another developer familiar with the domain.
### Global rollout on production
For visibility, all `/chatops` commands that target production should be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
and cross-posted (with the command results) to the responsible team's Slack channel (`#<slack-channel-of-dri-team>`).
-[ ] (Optional) [Incrementally roll out](https://docs.gitlab.com/ee/development/feature_flags/controls.html#process) the feature on production environment.
- Between every step wait for at least 15 minutes and monitor the appropriate graphs on https://dashboards.gitlab.net.
- Perform **actor-based** rollout: `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
- [ ] Enable the feature globally on production environment: `/chatops run feature set <feature-flag-name> true`
- [ ] Observe appropriate graphs on https://dashboards.gitlab.net and verify that services are not affected.
-[ ] Leave a comment on [the feature issue][main-issue] announcing that the feature has been globally enabled.
-[ ] Wait for [at least one day for the verification term](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release).
### (Optional) Release the feature with the feature flag
**WARNING:** This approach has the downside that it makes it difficult for us to
[clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) the flag.
For example, on-premise users could disable the feature on their GitLab instance. But when you
remove the flag at some point, they suddenly see the feature as enabled and they can't roll it back
to the previous behavior. To avoid this potential breaking change, use this approach only for urgent
matters.
<details><summary>See instructions if you're sure about enabling the feature globally through the feature flag definition</summary>
If you're still unsure whether the feature is [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release)
but want to release it in the current milestone, you can change the default state of the feature flag to be enabled.
To do so, follow these steps:
- [ ] Create a merge request with the following changes. Ask for review and merge it.
- [ ] If feature was enabled for various actors, ensure the feature has been enabled globally on production `/chatops run feature get <feature-flag-name>`. If the feature has not been globally enabled then enable the feature globally using: `/chatops run feature set <feature-flag-name> true`
-[ ] Set the `default_enabled` attribute in [the feature flag definition](https://docs.gitlab.com/ee/development/feature_flags/#feature-flag-definition-and-validation) to `true`.
-[ ] Decide [which changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog) is needed.
- [ ] Ensure that the default-enabling MR has been included in the release package.
If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>`
- [ ] Consider cleaning up the feature flag from all environments by running these chatops command in `#production` channel. Otherwise these settings may override the default enabled: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
-[ ] Close [the feature issue][main-issue] to indicate the feature will be released in the current milestone.
-[ ] Set the next milestone to this rollout issue for scheduling [the flag removal](#release-the-feature).
-[ ] (Optional) You can [create a separate issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) for scheduling the steps below to [Release the feature](#release-the-feature).
- [ ] Set the title to "[Feature flag] Cleanup `<feature-flag-name>`".
- [ ] Execute the `/copy_metadata <this-rollout-issue-link>` quick action to copy the labels from this rollout issue.
- [ ] Link this rollout issue as a related issue.
- [ ] Close this rollout issue.
</details>
### Release the feature
After the feature has been [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release),
the [clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up)
should be done as soon as possible to permanently enable the feature and reduce complexity in the
codebase.
You can either [create a follow-up issue for Feature Flag Cleanup](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) or use the checklist below in this same issue.
<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
- [ ] Create a merge request to remove the `<feature-flag-name>` feature flag. Ask for review/approval/merge as usual. The MR should include the following changes:
- Remove all references to the feature flag from the codebase.
- Remove the YAML definitions for the feature from the repository.
- [ ] Ensure that the cleanup MR has been included in the release package.
If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>`
-[ ] Close [the feature issue][main-issue] to indicate the feature will be released in the current milestone.
- [ ] Clean up the feature flag from all environments by running these chatops command in `#production` channel: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
- [ ] Close this rollout issue.
## Rollback Steps
- [ ] This feature can be disabled on production by running the following Chatops command:
```
/chatops run feature set <feature-flag-name> false
```
- [ ] Disable the feature flag on non-production environments:
```
/chatops run feature set <feature-flag-name> false --dev --pre --staging --staging-ref
```
- [ ] Delete feature flag from all environments:
```
/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production
<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-->
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
