Add latest changes from gitlab-org/gitlab@14-8-stable-eev14.8.0-rc42

12 files changed, 195 insertions, 61 deletions

diff --git a/.gitlab/issue_templates/Actionable Insight.md b/.gitlab/issue_templates/Actionable Insight - Exploration needed.md
index f4724d66a1b..76316fc626d 100644
--- a/.gitlab/issue_templates/Actionable Insight.md
+++ b/.gitlab/issue_templates/Actionable Insight - Exploration needed.md
@@ -1,13 +1,15 @@
-<!-- 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 -->
+<!-- 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 
+
+This issue template is for an actionable insight that requires further exploration.-->
 
 ### Insight
-<!-- Describe the insight itself: often the problem, finding, or observation. -->
+<!-- Describe the insight itself: often the problem, finding, or observation.-->
 
 ### Supporting evidence
 <!-- Describe why the problem is happening, or more details behind the finding or observation. Try to include quotes or specific data collected. Feel free to link the Actionable insight from Dovetail here if applicable instead of retyping details. -->
 
 ### Action
-<!--Describe the next step or action that needs to take place as a result of the research. The action should be clearly defined, achievable, and directly tied back to the insight. Make sure to use directive terminology, such as: conduct, explore, redesign, etc. -->
+<!--Since this is an actionable insight that requires further exploration, ensure the action is algned to that. Describe the next step or action that needs to take place as a result of the research. The action should be clearly defined, achievable, and directly tied back to the insight. Make sure to use directive terminology, such as: conduct, explore, redesign, etc. -->
 
 ### Resources
  <!--Add resources as links below or as related issues. -->
@@ -26,5 +28,5 @@
 
 
 /confidential
-/label ~"Actionable Insight"
+/label ~"Actionable Insight::Exploration needed"
 
diff --git a/.gitlab/issue_templates/Actionable Insight - Product change.md b/.gitlab/issue_templates/Actionable Insight - Product change.md
new file mode 100644
index 00000000000..6c030220636
--- /dev/null
+++ b/.gitlab/issue_templates/Actionable Insight - Product change.md
@@ -0,0 +1,33 @@
+<!-- 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 
+
+This issue template is for an actionable insight that requires a change in the product.-->
+
+### Insight
+<!-- Describe the insight itself: often the problem, finding, or observation.-->
+
+### Supporting evidence
+<!-- Describe why the problem is happening, or more details behind the finding or observation. Try to include quotes or specific data collected. Feel free to link the Actionable insight from Dovetail here if applicable instead of retyping details. -->
+
+### Action
+<!--Since this is an actionable insight that requires a change in the product, ensure the action is algned to that. Describe the next step or action that needs to take place as a result of the research. The action should be clearly defined, achievable, and directly tied back to the insight. Make sure to use directive terminology, such as: change, update, add/remove, etc. -->
+
+### Resources
+ <!--Add resources as links below or as related issues. -->
+
+- :dove: [Dovetail project](Paste URL for Dovetail project here)
+- :mag: [Research issue](Paste URL for research issue here)
+- :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::Product change"
+/label ~"SUS"
+
diff --git a/.gitlab/issue_templates/Deprecations.md b/.gitlab/issue_templates/Deprecations.md
index 85db4314233..cea010153bb 100644
--- a/.gitlab/issue_templates/Deprecations.md
+++ b/.gitlab/issue_templates/Deprecations.md
@@ -1,3 +1,5 @@
+For guidance on the overall deprecations, removals and breaking changes workflow, please visit https://about.gitlab.com/handbook/product/gitlab-the-product/#breaking-changes-deprecations-and-removing-features
+
 <!-- Use this template as a starting point for deprecations. -->
 
 ### Deprecation Summary
@@ -37,23 +39,27 @@ Which tier is this feature available in?
 - [ ] @mention your stage's stable counterparts 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 `@williamchia`
+       - 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`
 
-- [ ] @mention your GPM 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.
+- [ ] `@mention` your GPM 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
+### 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. Also, include a link to the removal issue if relevant.
+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.
@@ -71,4 +77,4 @@ Use the following resources to find the appropriate labels:
 <!-- Identifies that this Issue is related to deprecating a feature -->
 /label ~"type::deprecation"
 
-<!-- Add the ~"breaking change" label to this issue if necessary -->
\ No newline at end of file
+<!-- Add the ~"breaking change" label to this issue if necessary -->
diff --git a/.gitlab/issue_templates/Feature Flag Cleanup.md b/.gitlab/issue_templates/Feature Flag Cleanup.md
new file mode 100644
index 00000000000..eedb35a4b5f
--- /dev/null
+++ b/.gitlab/issue_templates/Feature Flag Cleanup.md
@@ -0,0 +1,52 @@
+<!-- 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. -->
+
+## 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 -->
+- [ ] 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.
+    - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
+- [ ] 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.
+- [ ] Clean up the feature flag from all environments by running these chatops command in `#production` channel:
+    - [ ] `/chatops run feature delete <feature-flag-name> --dev`
+    - [ ] `/chatops run feature delete <feature-flag-name> --staging`
+    - [ ] `/chatops run feature delete <feature-flag-name>`
+- [ ] Close this rollout issue.
+
+
+/label ~"feature flag" ~"type::feature" ~"feature::addition"
+/assign DRI
diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md
index 86f356daf90..590e627df75 100644
--- a/.gitlab/issue_templates/Feature Flag Roll Out.md
+++ b/.gitlab/issue_templates/Feature Flag Roll Out.md
@@ -121,7 +121,7 @@ To do so, follow these steps:
     - [ ] `/chatops run auto_deploy status <merge-commit-of-default-enabling-mr>`
 - [ ] Close [the feature issue](ISSUE LINK) 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 for scheduling the steps below to [Release the feature](#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.
@@ -141,6 +141,8 @@ the [clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.htm
 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 `<feature-flag-name>` feature flag. Ask for review and merge it.
     - [ ] Remove all references to the feature flag from the codebase.
diff --git a/.gitlab/issue_templates/Feature Proposal - lean.md b/.gitlab/issue_templates/Feature Proposal - lean.md
index c826abe7e10..53ad17bbf39 100644
--- a/.gitlab/issue_templates/Feature Proposal - lean.md
+++ b/.gitlab/issue_templates/Feature Proposal - lean.md
@@ -38,7 +38,7 @@ Personas are described at https://about.gitlab.com/handbook/marketing/product-ma
 
 -->
 
-### Metrics
+### Feature Usage Metrics
 
 <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
 
diff --git a/.gitlab/issue_templates/Feature proposal - detailed.md b/.gitlab/issue_templates/Feature proposal - detailed.md
index f7d0567f806..78faf146fbe 100644
--- a/.gitlab/issue_templates/Feature proposal - detailed.md
+++ b/.gitlab/issue_templates/Feature proposal - detailed.md
@@ -31,14 +31,6 @@ Personas are described at https://about.gitlab.com/handbook/marketing/product-ma
 * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
 -->
 
-### Metrics 
-
-<!-- How are you going to track uage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
-
-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
-
--->
-
 ### User experience goal
 
 <!-- What is the single user experience workflow this problem addresses?
@@ -63,7 +55,12 @@ Consider adding checkboxes and expectations of users with certain levels of memb
 * [ ] Add expected impact to Reporter (20) members
 * [ ] Add expected impact to Developer (30) members
 * [ ] Add expected impact to Maintainer (40) members
-* [ ] Add expected impact to Owner (50) members -->
+* [ ] Add expected impact to Owner (50) members 
+
+Please consider performing a threat model for the code changes that are introduced as part of this feature. To get started, refer to our Threat Modeling handbook page https://about.gitlab.com/handbook/security/threat_modeling/#threat-modeling. 
+
+Don't hesitate to reach out to the Application Security Team (`@gitlab-com/gl-security/appsec`) to discuss any security concerns.
+-->
 
 ### Documentation
 
@@ -94,6 +91,14 @@ See the test engineering planning process and reach out to your counterpart Soft
 * Ultimate/Gold
 -->
 
+### Feature Usage Metrics 
+
+<!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
+
+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 does success look like, and how can we measure that?
 
 <!--
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 256bddcbdab..6d37fc678af 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
@@ -130,25 +130,23 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
     FAILED_VERIFICATION_INDEX_NAME = "index_cool_widget_states_failed_verification"
     NEEDS_VERIFICATION_INDEX_NAME = "index_cool_widget_states_needs_verification"
 
-    disable_ddl_transaction!
+    enable_lock_retries!
 
     def up
-      with_lock_retries do
-        create_table :cool_widget_states, id: false do |t|
-          t.references :cool_widget, primary_key: true, null: false, foreign_key: { on_delete: :cascade }
-          t.integer :verification_state, default: 0, limit: 2, null: false
-          t.column :verification_started_at, :datetime_with_timezone
-          t.datetime_with_timezone :verification_retry_at
-          t.datetime_with_timezone :verified_at
-          t.integer :verification_retry_count, limit: 2
-          t.binary :verification_checksum, using: 'verification_checksum::bytea'
-          t.text :verification_failure, limit: 255
-
-          t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
-          t.index :verified_at, where: "(verification_state = 0)", order: { verified_at: 'ASC NULLS FIRST' }, name: PENDING_VERIFICATION_INDEX_NAME
-          t.index :verification_retry_at, where: "(verification_state = 3)", order: { verification_retry_at: 'ASC NULLS FIRST' }, name: FAILED_VERIFICATION_INDEX_NAME
-          t.index :verification_state, where: "(verification_state = 0 OR verification_state = 3)", name: NEEDS_VERIFICATION_INDEX_NAME
-        end
+      create_table :cool_widget_states, id: false do |t|
+        t.datetime_with_timezone :verification_started_at
+        t.datetime_with_timezone :verification_retry_at
+        t.datetime_with_timezone :verified_at
+        t.references :cool_widget, primary_key: true, null: false, foreign_key: { on_delete: :cascade }
+        t.integer :verification_state, default: 0, limit: 2, null: false
+        t.integer :verification_retry_count, limit: 2
+        t.binary :verification_checksum, using: 'verification_checksum::bytea'
+        t.text :verification_failure, limit: 255
+
+        t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
+        t.index :verified_at, where: "(verification_state = 0)", order: { verified_at: 'ASC NULLS FIRST' }, name: PENDING_VERIFICATION_INDEX_NAME
+        t.index :verification_retry_at, where: "(verification_state = 3)", order: { verification_retry_at: 'ASC NULLS FIRST' }, name: FAILED_VERIFICATION_INDEX_NAME
+        t.index :verification_state, where: "(verification_state = 0 OR verification_state = 3)", name: NEEDS_VERIFICATION_INDEX_NAME
       end
     end
 
@@ -489,7 +487,7 @@ That's all of the required database changes.
   module Geo
     class CoolWidgetState < ApplicationRecord
       include EachBatch
-      
+
       self.primary_key = :cool_widget_id
 
       belongs_to :cool_widget, inverse_of: :cool_widget_state
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 44b80158e51..35bb28ad170 100644
--- a/.gitlab/issue_templates/Geo Replicate a new blob type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new blob type.md
@@ -132,25 +132,23 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
     FAILED_VERIFICATION_INDEX_NAME = "index_cool_widget_states_failed_verification"
     NEEDS_VERIFICATION_INDEX_NAME = "index_cool_widget_states_needs_verification"
 
-    disable_ddl_transaction!
+    enable_lock_retries!
 
     def up
-      with_lock_retries do
-        create_table :cool_widget_states, id: false do |t|
-          t.references :cool_widget, primary_key: true, null: false, foreign_key: { on_delete: :cascade }
-          t.integer :verification_state, default: 0, limit: 2, null: false
-          t.column :verification_started_at, :datetime_with_timezone
-          t.datetime_with_timezone :verification_retry_at
-          t.datetime_with_timezone :verified_at
-          t.integer :verification_retry_count, limit: 2
-          t.binary :verification_checksum, using: 'verification_checksum::bytea'
-          t.text :verification_failure, limit: 255
-
-          t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
-          t.index :verified_at, where: "(verification_state = 0)", order: { verified_at: 'ASC NULLS FIRST' }, name: PENDING_VERIFICATION_INDEX_NAME
-          t.index :verification_retry_at, where: "(verification_state = 3)", order: { verification_retry_at: 'ASC NULLS FIRST' }, name: FAILED_VERIFICATION_INDEX_NAME
-          t.index :verification_state, where: "(verification_state = 0 OR verification_state = 3)", name: NEEDS_VERIFICATION_INDEX_NAME
-        end
+      create_table :cool_widget_states, id: false do |t|
+        t.datetime_with_timezone :verification_started_at
+        t.datetime_with_timezone :verification_retry_at
+        t.datetime_with_timezone :verified_at
+        t.references :cool_widget, primary_key: true, null: false, foreign_key: { on_delete: :cascade }
+        t.integer :verification_state, default: 0, limit: 2, null: false
+        t.integer :verification_retry_count, limit: 2
+        t.binary :verification_checksum, using: 'verification_checksum::bytea'
+        t.text :verification_failure, limit: 255
+
+        t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
+        t.index :verified_at, where: "(verification_state = 0)", order: { verified_at: 'ASC NULLS FIRST' }, name: PENDING_VERIFICATION_INDEX_NAME
+        t.index :verification_retry_at, where: "(verification_state = 3)", order: { verification_retry_at: 'ASC NULLS FIRST' }, name: FAILED_VERIFICATION_INDEX_NAME
+        t.index :verification_state, where: "(verification_state = 0 OR verification_state = 3)", name: NEEDS_VERIFICATION_INDEX_NAME
       end
     end
 
@@ -453,7 +451,7 @@ That's all of the required database changes.
   module Geo
     class CoolWidgetState < ApplicationRecord
       include EachBatch
-      
+
       self.primary_key = :cool_widget_id
 
       belongs_to :cool_widget, inverse_of: :cool_widget_state
diff --git a/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md b/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
new file mode 100644
index 00000000000..4544e675256
--- /dev/null
+++ b/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
@@ -0,0 +1,38 @@
+<!--
+## Implementation Issue To-Do list 
+(_NOTE: This section can be removed when the issue is ready for creation_)
+- [ ] Ensure that issue title is concise yet descriptive
+- [ ] Add `Frontend :` or `Backend: ` per group [naming conventions](https://about.gitlab.com/handbook/engineering/development/ops/verify/pipeline-authoring/#splitting-issues)
+- [ ] Ensure the issue containing the feature or change proposal and related discussions is linked as related to this implementation issue.
+- [ ] Aside from default labeling, please make sure to include relevant labels for `type::`, `workflow::`, and `~frontend`/`~backend` labeling.
+- [ ] Issues with user-facing changes should include the `~UX` label.
+-->
+
+## Summary
+
+## Proposal
+
+## Implementation Table
+
+<!--
+_NOTE: If the issue is not part of an epic, the implementation table can be removed. If it is part of an epic, make sure that the implementation table below mirrors the corresponding epic's implementation table content._
+-->
+
+
+| Group | Issue Link |
+| ------ | ------ |
+| ~backend | :point_left: You are here |
+| ~frontend | [#123123](url) |
+
+<!--
+## Documentation 
+
+_NOTE: This section is optional, but can be used for easy access to any relevant documentation URLs._
+-->
+
+## Links/References
+
+
+
+
+/label ~"group::pipeline authoring" ~"Category:Pipeline Authoring" ~"section::ops" ~"devops::verify" ~"workflow::planning breakdown"
diff --git a/.gitlab/issue_templates/Problem Validation.md b/.gitlab/issue_templates/Problem Validation.md
index 3f92510b6af..dee026ee752 100644
--- a/.gitlab/issue_templates/Problem Validation.md
+++ b/.gitlab/issue_templates/Problem Validation.md
@@ -1,4 +1,4 @@
-<!-- This template is used as a starting point for understing and articulating a customer problem.
+<!-- This template is used as a starting point for understanding and articulating a customer problem.
 Learn more about it in the handbook: https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation 
 -->
 
diff --git a/.gitlab/issue_templates/Security developer workflow.md b/.gitlab/issue_templates/Security developer workflow.md
index e63727fe484..5c1b669a88f 100644
--- a/.gitlab/issue_templates/Security developer workflow.md
+++ b/.gitlab/issue_templates/Security developer workflow.md
@@ -9,14 +9,13 @@ Set the title to: `Description of the original issue`
 ## Prior to starting the security release work
 
 - [ ] Read the [security process for developers] if you are not familiar with it.
-- [ ] Make sure the issue really needs to follow the security release workflow.
-  - Verify if the issue you're working on `gitlab-org/gitlab` is confidential, if it's public fix should be placed on GitLab canonical and no backports are required.
-  - If the issue you're fixing doesn't appear to be something that can be exploited by a malicious person and is instead simply a security enhancement do not hesitate to ping `@gitlab-com/gl-security/appsec` to discuss if the issue can be fixed in the canonical repository.
+- [ ] Make sure the [issue really needs to follow the security release workflow].
 - [ ] **IMPORTANT**: Mark this [issue as linked] to the Security Release Tracking Issue. You can find it [here](https://gitlab.com/gitlab-org/gitlab/-/issues?sort=created_date&state=opened&label_name[]=upcoming+security+release). This issue
 MUST be linked for the release bot to know that the associated merge requests should be merged for this security release.
 - Fill out the [Links section](#links):
   - [ ] Next to **Issue on GitLab**, add a link to the `gitlab-org/gitlab` issue that describes the security vulnerability.
 - [ ] Add one of the `~severity::x` labels to the issue and all associated merge requests.
+- [ ] If this change affects the public interface (public API or UI) of the product, post in the `#support_gitlab-com` Slack channel  to explain the impact and discuss a mitigation plan for users that might be affected. If you need Support feedback or approval, reach out in `#spt_managers` Slack channel or mention `@gitlab-com/support/managers`.
 
 ## Development
 
@@ -71,5 +70,6 @@ After your merge request has been approved according to our [approval guidelines
 [security Release merge request template]: https://gitlab.com/gitlab-org/security/gitlab/blob/master/.gitlab/merge_request_templates/Security%20Release.md
 [approval guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
 [issue as linked]: https://docs.gitlab.com/ee/user/project/issues/related_issues.html#add-a-linked-issue
+[issue really needs to follow the security release workflow]: https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md#making-sure-the-issue-needs-to-follow-the-security-release-workflow
 
 /label ~security