Update Feature Flag removal criteria

This commit clarifies the removal criteria

doc/development/feature_flags/controls.md

@@ -210,11 +210,20 @@ actors.
 Feature.enabled?(:some_feature, group)
 ```
 
-NOTE:
-
+NOTE: **Note:**
 **Percentage of time** rollout is not a good idea if what you want is to make sure a feature
 is always on or off to the users. In that case, **Percentage of actors** rollout is a better method.
 
+Lastly, to verify that the feature is deemed stable in as many cases as possible,
+you should fully roll out the feature by enabling the flag **globally** by running:
+
+```shell
+/chatops run feature set some_feature true
+```
+
+This changes the feature flag state to be **enabled** always, which overrides the
+existing gates (e.g. `--group=gitlab-org`) in the above processes.
+
 ### Feature flag change logging
 
 Any feature flag change that affects GitLab.com (production) will

doc/development/feature_flags/process.md

@@ -71,7 +71,9 @@ absolutely no way to use the feature until it is enabled.
 In order to build a final release and present the feature for self-managed
 users, the feature flag should be at least defaulted to **on**. If the feature
 is deemed stable and there is confidence that removing the feature flag is safe,
-consider removing the feature flag altogether.
+consider removing the feature flag altogether. It's _strongly_ recommended that
+the feature flag is [enabled **globally** on **production**](./controls.md#enabling-a-feature-for-gitlabcom) for **at least one day**
+before making this decision. Unexpected bugs are sometimes discovered during this period.
 
 The process for enabling features that are disabled by default can take 5-6 days
 from when the merge request is first reviewed to when the change is deployed to