Merge branch 'rollout-template-update' into 'master'

Update ff rollout template and docs

See merge request gitlab-org/gitlab!74485

.gitlab/issue_templates/Feature Flag Roll Out.md

@@ -48,6 +48,12 @@ Example below:
 ### What can we monitor to detect problems with this?
 
 <!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
+_Consider mentioning checks for 5xx errors or other anomalies like an increase in redirects 
+(302 HTTP response status)_
+
+### What can we check for monitoring production after rollouts?
+
+_Consider adding links to check for Sentry errors, Production logs for 5xx, 302s, etc._
 
 ## Rollout Steps
 
@@ -84,7 +90,7 @@ Example below:
   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 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)).
+- [ ] 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)).
 
 ### Global rollout on production
 

doc/development/feature_flags/controls.md

@@ -90,9 +90,9 @@ This depends on the feature and what sort of impact it might have.
 
 Guidelines:
 
-1. If the feature meets the requirements for creating a [Change Management](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process) issue, create a Change Management issue per [criticality guidelines](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#change-request-workflows).
-1. For simple, low-risk, easily reverted features, proceed and [enable the feature in `#production`](#process).
-1. For features that impact the user experience, consider notifying `#support_gitlab-com` beforehand.
+- Consider notifying `#support_gitlab-com` beforehand. So in case if the feature has any side effects on user experience, they can mitigate and disable the feature flag to reduce some impact.
+- If the feature meets the requirements for creating a [Change Management](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process) issue, create a Change Management issue per [criticality guidelines](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#change-request-workflows).
+- For simple, low-risk, easily reverted features, proceed and [enable the feature in `#production`](#process).
 
 #### Process