Add latest changes from gitlab-org/gitlab@14-3-stable-eev14.3.0-rc42

10 files changed, 152 insertions, 46 deletions

diff --git a/.gitlab/issue_templates/Actionable Insight.md b/.gitlab/issue_templates/Actionable Insight.md
index df519f81799..f4724d66a1b 100644
--- a/.gitlab/issue_templates/Actionable Insight.md
+++ b/.gitlab/issue_templates/Actionable Insight.md
@@ -1,4 +1,4 @@
-<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Learn more in the handbook here: https://about.gitlab.com/handbook/engineering/ux/ux-research-training/research-insights/#actionable-insights -->
+<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Please follow the tasks outlined in this issue for best results. Learn more in the handbook here: https://about.gitlab.com/handbook/engineering/ux/ux-research-training/research-insights/#actionable-insights -->
 
 ### Insight
 <!-- Describe the insight itself: often the problem, finding, or observation. -->
@@ -17,12 +17,14 @@
 - :footprints: [Follow-up issue or epic](Paste URL for follow-up issue or epic here)
 
 ### Tasks
+ <!--Fill out these tasks in order to consider an Actionable Insight complete. Actionable Insights are created as confidential by default, but can be made non-confidential if the insight does not include information about competitors from a Competitor Evaluation or any other confidential information. -->
 - [ ] Assign this issue to the appropriate Product Manager, Product Designer, or UX Researcher.
 - [ ] Add the appropriate `Group` (such as `~"group::source code"`) label to the issue.  This helps identify and track actionable insights at the group level.
 - [ ] Link this issue back to the original research issue in the GitLab UX Research project and the Dovetail project.
+- [ ] Adjust confidentiality of this issue if applicable
 
 
 
-
+/confidential
 /label ~"Actionable Insight"
 
diff --git a/.gitlab/issue_templates/experiment_tracking_template.md b/.gitlab/issue_templates/Experiment Rollout.md
index c653a3a2d40..c5fdc739943 100644
--- a/.gitlab/issue_templates/experiment_tracking_template.md
+++ b/.gitlab/issue_templates/Experiment Rollout.md
@@ -1,16 +1,14 @@
-<!-- Title suggestion: [Experiment Tracking] experiment-key - description of experiment -->
+<!-- Title suggestion: [Experiment Rollout] experiment-key - description of experiment -->
 
-## What
+## Summary
 
-Track the status of an experiment through to removal.
+This issue tracks the rollout and status of an experiment through to removal.
 
-1. Experiment key: `<experiment-key>`
-1. Framework: `experimentation.rb` | `gitlab_experiment`
-1. Feature flag name: <experiment-key>_experiment_percentage` | `<experiment-key>`
-
-This is an experiment tracking issue for: `<issue or epic link>` 
-using the scoped [experiment label](https://about.gitlab.com/handbook/engineering/development/growth/#experiment-tracking-issue).
+1. Experiment key / feature flag name: `<experiment-key>`
+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. 
 
@@ -19,49 +17,65 @@ As well as defining the experiment rollout and cleanup, this issue incorporates
 - 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? Sentry errors reports can also be useful to review -->
 
-### Tracked data
+<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
+
+## Tracked data
 <!-- brief description or link to issue or Sisense dashboard -->
- 
- Note: you can utilize [CXL calculator](https://cxl.com/ab-test-calculator/) to determine if your experiment has reached signifigance, it also includes an estimate for how much longer an experiment will need to run for before reaching signifigance.
 
-### Staging Test
-<!-- For experiments using `experimentation.rb`: To force this experiment on staging use `?force_experiment=<experiment-key>` -->
-<!-- list any steps required to setup this experiment, and link to a separate Staging environment test issue is applicable -->
+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.
 
-<!-- uncomment if testing with specific groups/projects on GitLab.com
-## Beta groups/projects
+## Rollout plan
+<!-- Add an overview and method for modifying the feature flag -->
 
-If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.
+- 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.
 
-- `gitlab-org/gitlab` project
-- `gitlab-org`/`gitlab-com` groups
-- ...
--->
+`/chatops run feature set <experiment-key> <rollout-percentage> --actors`
 
-### Experiment tracking log
-<!-- Add an overview and method for modifying the feature flag
+### Status
 
-* Runtime: 30 days or until we reach statistical significance
-* We will roll this out behind a feature flag and expose this to 20% of users to start then ramp it up from there.
-* feature flag based on experiment key `<experiment-key>` (see `experimentation.rb` in GitLab, append '_experiment_percentage')
 
-`/chatops run feature set <experiment-key>_experiment_percentage <INITIAL_PERCENTAGE>`
--->
-<!-- Add bullet points to track changes to the rollout of this experiment (feature flag changes) 
+#### Preferred workflow
 
-* YYYY-MM-DD UTC - initial rollout to 20% of users
-* TBD - review - increase to 50% of users
--->
+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)
+- [Experiment rollout board](https://gitlab.com/groups/gitlab-org/-/boards/1352542)
+
+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 -->
@@ -69,7 +83,7 @@ If applicable, any groups/projects that are happy to have this feature turned on
 ## Roll Out Steps
 
 - [ ] Confirm that QA tests pass with the feature flag enabled (if you're unsure how, contact the relevant [stable counterpart in the Quality department](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors))
-- [ ] Enable on staging (`/chatops run feature set feature_name true --staging`)
+- [ ] Enable on staging (`/chatops run feature set <experiment-key> 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_name true`)
@@ -88,8 +102,8 @@ If applicable, any groups/projects that are happy to have this feature turned on
 - [ ] This feature can be disabled by running the following Chatops command:
 
 ```
-/chatops run feature set feature_name false
+/chatops run feature set <experiment-key> false
 ```
 
-/label ~"feature flag" ~"devops::growth" ~"growth experiment" ~"experiment tracking" ~Engineering ~"workflow::scheduling" ~"experiment::pending"
-
+/label ~"feature flag" ~"devops::growth" ~"growth experiment" ~"experiment-rollout" ~Engineering ~"workflow::scheduling" ~"experiment::pending"
+/milestone %"Next 1-3 releases" 
diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md
index ec6e5dfd7d4..1576f6e8f53 100644
--- a/.gitlab/issue_templates/Feature Flag Roll Out.md
+++ b/.gitlab/issue_templates/Feature Flag Roll Out.md
@@ -38,6 +38,8 @@ Are there any other stages or teams involved that need to be kept in the loop?
 <!-- If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example. -->
 
 - `gitlab-org/gitlab` project
+- `gitlab-org/gitlab-foss` project
+- `gitlab-com/www-gitlab-com` project
 - `gitlab-org`/`gitlab-com` groups
 - ...
 
@@ -79,19 +81,24 @@ Are there any other stages or teams involved that need to be kept in the loop?
 - [ ] Ensure that documentation has been updated ([More info](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#features-that-became-enabled-by-default)).
 - [ ] Announce on [the feature issue](ISSUE LINK) an estimated time this will be enabled on GitLab.com.
 - [ ] If the feature might impact the user experience, notify `#support_gitlab-com` 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)).
-- [ ] If the feature flag in code has [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), enable it on GitLab.com for [testing groups/projects](#testing-groupsprojectsusers).
-    - [ ] `/chatops run feature set --<actor-type>=<actor> <feature-flag-name> true`
-- [ ] Verify that the feature works as expected. Posting the QA result in this issue is preferable.
 
 ### Global rollout on production
 
+All `/chatops` commands that target production should be done in the `#production` slack channel for visibility.
+
+- [ ] Confirm the feature flag is enabled on `staging` without incident
+- [ ] Roll out the feature to targeted testing projects/groups first
+    - [ ] `/chatops run feature set --project=gitlab-org/gitlab <feature-flag-name> true`
+    - [ ] `/chatops run feature set --project=gitlab-org/gitlab-foss <feature-flag-name> true`
+    - [ ] `/chatops run feature set --project=gitlab-com/www-gitlab-com <feature-flag-name> true`
+
 - [ ] [Incrementally roll out](https://docs.gitlab.com/ee/development/feature_flags/controls.html#process) the feature.
   - If the feature flag in code has [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), perform **actor-based** rollout.
     - [ ] `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
   - If the feature flag in code does **NOT** have [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), perform time-based rollout (**random** rollout).
     - [ ] `/chatops run feature set <feature-flag-name> <rollout-percentage>`
-  - Enable the feature globally on production environment.
-    - [ ] `/chatops run feature set <feature-flag-name> true`
+- [ ] Verify the change has the desired outcome with the limited rollout before enabling the feature globally on production.
+- [ ] Enable the feature globally on production environment. `/chatops run feature set <feature-flag-name> true`
 - [ ] Announce on [the feature issue](ISSUE LINK) 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).
 
diff --git a/.gitlab/issue_templates/Feature proposal - detailed.md b/.gitlab/issue_templates/Feature proposal - detailed.md
index 9b72ed5a01c..9759bb7e2dc 100644
--- a/.gitlab/issue_templates/Feature proposal - detailed.md
+++ b/.gitlab/issue_templates/Feature proposal - detailed.md
@@ -91,7 +91,7 @@ See the test engineering planning process and reach out to your counterpart Soft
 <!--
 Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this.
 
-Create tracking issue using the the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
+Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
 -->
 
 ### What is the type of buyer?
diff --git a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
index 73233644d37..476ee14a632 100644
--- a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
@@ -826,5 +826,7 @@ Individual Cool Widget replication and verification data should now be available
         feature_flag: :geo_cool_widget_replication # REMOVE THIS LINE
   ```
 
+- [ ] Run `bundle exec rake gitlab:graphql:compile_docs` after the step above to regenerate the GraphQL docs.
+
 - [ ] Add a row for Cool Widgets to the `Data types` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#data-types)
 - [ ] Add a row for Cool Widgets to the `Limitations on replication/verification` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#limitations-on-replicationverification). If the row already exists, then update it to show that Replication and Verification is released in the current version.
diff --git a/.gitlab/issue_templates/Geo Replicate a new blob type.md b/.gitlab/issue_templates/Geo Replicate a new blob type.md
index cc5a606d68b..aef983f6495 100644
--- a/.gitlab/issue_templates/Geo Replicate a new blob type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new blob type.md
@@ -794,5 +794,7 @@ Individual Cool Widget replication and verification data should now be available
         feature_flag: :geo_cool_widget_replication # REMOVE THIS LINE
   ```
 
+- [ ] Run `bundle exec rake gitlab:graphql:compile_docs` after the step above to regenerate the GraphQL docs.
+
 - [ ] Add a row for Cool Widgets to the `Data types` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#data-types)
 - [ ] Add a row for Cool Widgets to the `Limitations on replication/verification` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#limitations-on-replicationverification). If the row already exists, then update it to show that Replication and Verification is released in the current version.
diff --git a/.gitlab/issue_templates/InfraDev.md b/.gitlab/issue_templates/InfraDev.md
new file mode 100644
index 00000000000..bc0e65c3c22
--- /dev/null
+++ b/.gitlab/issue_templates/InfraDev.md
@@ -0,0 +1,56 @@
+<!--
+Triage of infradev Issues is desired to occur asynchronously.
+For maximum efficiency, please ensure the following, so that your infradev issues can gain maximum traction.
+
+https://about.gitlab.com/handbook/engineering/workflow/#a-guide-to-creating-effective-infradev-issues
+-->
+
+## Summary
+<!--
+Clearly state the scope of the problem, and how it affects GitLab.com
+-->
+
+
+## Impact
+<!--
+- Quantify the effect of the problem to help ensure that correct prioritization occurs.
+- Include costs to availability. The Incident Budget Explorer dashboard can help here.
+- Include the number of times alerts have fired owing to the problem, how much time was spent dealing with the problem, and how many people were involved.
+- Link to affected incidents, and cross-reference them as related issues.
+- Include screenshots of visualization from Grafana or Kibana.
+- Always include a permalink to the source of the screenshot so that others can investigate further.
+-->
+
+
+## Recommendation
+<!--
+Provide a clear, unambiguous, self-contained solution to the problem.
+-->
+
+
+## Verification
+<!--
+Provide a method for validating that the original issue still exists.
+
+Having a way of checking validity can save on a great deal of back-and-forth discussion between Infradev Triage participants including Engineering Managers, Directors and Product Managers and make space for other non-resolved issues to get scheduled sooner.
+
+Ideally, provide a link to a Thanos query or an ELK query and clear instructions on how to interpret the results to determine whether the problem is still occurring.
+-->
+
+
+<!--
+Workflow and other relevant labels
+
+/label ~"severity::"
+/label ~"priority::"
+/label ~"group::"
+/label ~"devops::"
+
+See also:
+- https://about.gitlab.com/handbook/engineering/quality/issue-triage/#availability
+- https://about.gitlab.com/handbook/product/categories/
+- https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml
+-->
+
+/label ~"infradev"
+/label ~"bug"
diff --git a/.gitlab/issue_templates/Navigation - Left Sidebar Proposals.md b/.gitlab/issue_templates/Navigation - Left Sidebar Proposals.md
new file mode 100644
index 00000000000..57d6d12267c
--- /dev/null
+++ b/.gitlab/issue_templates/Navigation - Left Sidebar Proposals.md
@@ -0,0 +1,15 @@
+<!-- This template is used for proposing changes to the left sidebar contextual navigation. This could include additions, removals, or general changes to overall hierarchy.-->
+
+### Proposal 
+
+<!-- Use this section to explain the proposed changes, including details around usage and business drivers. -->
+
+### Checklist
+
+- [ ] If your proposal includes changes to the top-level menu items within the left sidebar, engage the [Foundations Product Design Manager](https://about.gitlab.com/handbook/product/categories/#foundations-group) for approval. The Foundations DRI will work with UX partners in product design, research, and technical writing, as applicable.
+- [ ] Follow the [product development workflow](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation) validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is strongly encouraged.
+- [ ] Engage the [Editor](https://about.gitlab.com/handbook/engineering/development/dev/create-editor/) team to ensure your proposal is in alignment with holistic changes happening to the left side bar.
+- [ ] Consider whether you need to communicate the change somehow, or if you will have an interim period in the UI where your nav item will live in more than one place.
+- [ ] Once implemented, update this [navigation map in Mural](https://app.mural.co/t/gitlab2474/m/gitlab2474/1589571490215/261462d0beb3043979374623710d3f2d6cfec1cb) with your navigation change.
+
+/label ~UX ~"UI text" ~"documentation" ~"documentation" ~"Category:Navigation & Settings" ~"Category:Foundations" ~navigation 
diff --git a/.gitlab/issue_templates/Security developer workflow.md b/.gitlab/issue_templates/Security developer workflow.md
index 51e8ec378b2..7f2c54f4f49 100644
--- a/.gitlab/issue_templates/Security developer workflow.md
+++ b/.gitlab/issue_templates/Security developer workflow.md
@@ -29,6 +29,7 @@ After your merge request has been approved according to our [approval guidelines
 ## Backports
 
 - [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches
+   * The 3 stable branches correspond to the versions in the title of the Security Release Tracking Issue.
    * At this point, it might be easy to squash the commits from the MR into one
    * You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
 - [ ] Create each MR targeting the stable branch `X-Y-stable`, using the [Security Release merge request template].
diff --git a/.gitlab/issue_templates/Technical Evaluation.md b/.gitlab/issue_templates/Technical Evaluation.md
index 533a1343820..cf939725a78 100644
--- a/.gitlab/issue_templates/Technical Evaluation.md
+++ b/.gitlab/issue_templates/Technical Evaluation.md
@@ -5,6 +5,13 @@
 <!-- Describe the related issue and challenge we need to establish a proof of concept for-->
 * [Link to other Issue](link)
 
+### Tasks prior to evaluation
+
+<!-- Pre-evaluation tasks are critical and should be completed or confirmed by product managers if available -->
+
+- [ ] Clearly document the topic to evaluated in this issue description
+- [ ] Determine specific scope including time-bounds for investigation
+
 ### Tasks to  Evaluate
 
 <!-- Outline the tasks with issues that you need to evaluate as a part of the implementation issue -->