Merge branch 'docs-feature-flag-note' into 'master'

Updated feature flag documentation guidance

See merge request gitlab-org/gitlab!66783

doc/administration/feature_flags.md

@@ -31,16 +31,27 @@ These features can be enabled and disabled to allow or disallow users to use
 them. It can be done by GitLab administrators with access to GitLab Rails
 console.
 
+When you disable a feature flag, the feature is hidden from users and all of the functionality is turned off.
+For example, data is not recorded and services do not run.
+
 If you used a certain feature and identified a bug, a misbehavior, or an
 error, it's very important that you [**provide feedback**](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue[title]=Docs%20-%20feature%20flag%20feedback%3A%20Feature%20Name&issue[description]=Describe%20the%20problem%20you%27ve%20encountered.%0A%0A%3C!--%20Don%27t%20edit%20below%20this%20line%20--%3E%0A%0A%2Flabel%20~%22docs%5C-comments%22%20) to GitLab as soon
 as possible so we can improve or fix it while behind a flag. When you upgrade
 GitLab to an earlier version, the feature flag status may change.
 
-WARNING:
-Features deployed behind feature flags may not be ready for
-production use. However, disabling features behind flags that were deployed
-enabled by default may also present a risk. If they're enabled, we recommend
-you leave them as-is.
+## Risks when enabling features still in development
+
+Features that are disabled by default may change or be removed without notice in a future version of GitLab.
+
+Data corruption, stability degradation, or performance degradation might occur if
+you enable a feature that's disabled by default. Problems caused by using a default
+disabled feature aren't covered by GitLab support, unless you were directed by GitLab
+to enable the feature.
+
+## Risks when disabling released features
+
+In most cases, the feature flag code is removed in a future version of GitLab.
+If and when that occurs, from that point onward you can't keep the feature in a disabled state.
 
 ## How to enable and disable features behind flags
 

doc/administration/instance_limits.md

@@ -491,7 +491,7 @@ A runner's registration fails if it exceeds the limit for the scope determined b
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-job-log-limits). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 The job log file size limit is 100 megabytes by default. Any job that exceeds this value is dropped.

doc/api/graphql/custom_emoji.md

@@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-custom-emoji-api). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 To use custom emoji in comments and descriptions, you can add them to a group using the GraphQL API.

doc/api/group_protected_environments.md

@@ -14,7 +14,7 @@ type: concepts, howto
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](../ci/environments/protected_environments.md#enable-or-disable-group-level-protected-environments). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 Read more about [group-level protected environments](../ci/environments/protected_environments.md#group-level-protected-environments),

doc/api/index.md

@@ -254,7 +254,7 @@ tries to steal tokens from other jobs.
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-ci-job-token-scope-limit). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 You can limit the access scope of a project's CI/CD job token to increase the

doc/ci/environments/protected_environments.md

@@ -163,7 +163,7 @@ For more information, see [Deployment safety](deployment_safety.md).
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-group-level-protected-environments). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 Typically, large enterprise organizations have an explicit permission boundary

doc/ci/pipelines/index.md

@@ -362,7 +362,7 @@ you visualize the entire pipeline, including all cross-project inter-dependencie
 > - To disable in GitLab self-managed instances, ask a GitLab administrator to [disable it](#enable-or-disable-job-dependency-view). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/index.md#needs)

doc/ci/yaml/index.md

@@ -474,7 +474,7 @@ Use local includes instead of symbolic links.
 > - For GitLab self-managed instances, GitLab administrators can opt to disable it. **(CORE ONLY)**
 
 There can be
-[risks when disabling released features](../../user/feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 You can use wildcard paths (`*` and `**`) with `include:local`.

doc/development/documentation/feature_flags.md

@@ -8,7 +8,7 @@ description: "GitLab development - how to document features deployed behind feat
 
 # Document features deployed behind feature flags
 
-GitLab uses [Feature Flags](../feature_flags/index.md) to strategically roll
+GitLab uses [feature flags](../feature_flags/index.md) to strategically roll
 out the deployment of its own features. The way we document a feature behind a
 feature flag depends on its state (enabled or disabled). When the state
 changes, the developer who made the change **must update the documentation**
@@ -18,296 +18,85 @@ Every feature introduced to the codebase, even if it's behind a feature flag,
 must be documented. For context, see the
 [latest merge request that updated this guideline](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47917#note_459984428).
 
-## Criteria
+## Use a note to describe the state of the feature flag
 
-According to the process of [deploying GitLab features behind feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/):
+Information about feature flags should be in a **Note** at the start of the topic (just below the version history).
 
-> - _By default, feature flags should be off._
-> - _Feature flags should remain in the codebase for a short period as possible to reduce the need for feature flag accounting._
-> - _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._
+The note has three parts, and follows this structure:
 
-See how to document them below, according to the state of the flag:
-
-- [Features disabled by default](#features-disabled-by-default).
-- [Features that became enabled by default](#features-that-became-enabled-by-default).
-- [Features directly enabled by default](#features-directly-enabled-by-default).
-- [Features that can be enabled or disabled for a single project](#features-enabled-by-project).
-- [Features with the feature flag removed](#features-with-flag-removed).
-
-The [`**(FREE SELF)**`](styleguide/index.md#product-tier-badges) badge or equivalent for
-the feature's tier should be added to the line and heading that refers to
-enabling/disabling feature flags as Admin access is required to do so,
-therefore, it indicates that it cannot be done by regular users of GitLab.com.
-
-### Features disabled by default
-
-For features disabled by default, add or improve the docs with every change in line with the
-[definition of done](../contributing/merge_request_workflow.md#definition-of-done).
-
-Include details of the feature flag in the documentation:
-
-- Say that it's disabled by default.
-- Say whether it's enabled on GitLab.com.
-- If the feature can be enabled/disabled for a single project, add the
-  [by-project information](#features-enabled-by-project). Otherwise,
-  do not say anything about it.
-- Say whether it's recommended for production use.
-- Document how to enable and disable it, preferably at the end of the file.
-- Add a warning to the user saying that the feature might be disabled.
-
-For example, for a feature disabled by default, disabled on GitLab.com, cannot
-be enabled for a single project, and is not ready for production use:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), disabled by default.
-> - Disabled on GitLab.com.
-> - Not recommended for production use.
-> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#anchor-to-section). **(FREE SELF)**
-
-This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](<replace with path to>/user/feature_flags.md#risks-when-enabling-features-still-in-development).
-Refer to this feature's version history for more details.
-
-(...Regular content goes here...)
-
-<!-- Add this at the end of the file -->
-
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development and not ready for production use. It is
-deployed behind a feature flag that is **disabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can enable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:<feature flag>)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:<feature flag>)
-```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`, and
-`<replace with path to>`, and `#anchor-to-section` accordingly.
-
-### Features that became enabled by default
-
-For features that were released disabled by default but became enabled by
-default:
-
-- Say that it became enabled by default.
-- Say whether it's enabled on GitLab.com.
-- If the feature can be enabled/disabled for a single project, add the
-  [by-project information](#features-enabled-by-project). Otherwise,
-  do not say anything about it.
-- Say whether it's recommended for production use.
-- Document how to disable and enable it, preferably at the end of the file.
-- Add a warning to the user saying that the feature might be disabled.
-
-For example, for a feature initially deployed disabled by default, that became
-enabled by default, that is enabled on GitLab.com, and is ready for production
-use:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), disabled by default.
-> - [Enabled by default](link-to-issue) in GitLab 12.1.
-> - Enabled on GitLab.com.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(FREE SELF)**
-
-There can be
-[risks when disabling released features](<replace with path to>/user/feature_flags.md#risks-when-disabling-released-features).
-Refer to this feature's version history for more details.
-
-(...Regular content goes here...)
-
-<!-- Add this at the end of the file -->
-
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:<feature flag>)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:<feature flag>)
+```markdown
+NOTE:
+<Self-managed GitLab availability information.> <GitLab.com availability information.>
+<This feature is not ready for production use.>
 ```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`,
-`<replace with path to>`, and `#anchor-to-section` accordingly.
 
-### Features directly enabled by default
+### Self-managed GitLab availability information
 
-For features enabled by default:
+|If the feature is... | Use this text |
+|-|-|
+|Available|`On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable|`On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Available, per-group|`On self-managed GitLab, by default this feature is available. To hide the feature per group, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable, per-group|`On self-managed GitLab, by default this feature is not available. To make it available per group, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Available, per-project|`On self-managed GitLab, by default this feature is available. To hide the feature per project or for your entire instance, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable, per-project|`On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Available, per-user|`On self-managed GitLab, by default this feature is available. To hide the feature per user, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable, per-user|`On self-managed GitLab, by default this feature is not available. To make it available per user, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
 
-- Say it's enabled by default.
-- Say whether it's enabled on GitLab.com.
-- If the feature can be enabled/disabled for a single project, add the
-  [by-project information](#features-enabled-by-project). Otherwise,
-  do not say anything about it.
-- Say whether it's recommended for production use.
-- Document how to disable and enable it, preferably at the end of the file.
-- Add a warning to the user saying that the feature might be disabled.
+### GitLab.com availability information
 
-For example, for a feature enabled by default, enabled on GitLab.com, that
-cannot be enabled for a single project, and is ready for production use:
+|If the feature is... | Use this text |
+|-|-|
+|Available| `On GitLab SaaS, this feature is available.` |
+|Unavailable| `On GitLab SaaS, this feature is not available.`|
 
-````markdown
-# Feature Name
+### Optional information
 
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), enabled by default.
-> - Enabled on GitLab.com.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(FREE SELF)**
+If needed, you can add this sentence:
 
-There can be
-[risks when disabling released features](<replace with path to>/user/feature_flags.md#risks-when-disabling-released-features).
-Refer to this feature's version history for more details.
+`You should not use this feature for production environments.`
 
-(...Regular content goes here...)
+## Add version history text
 
-<!-- Add this at the end of the file -->
+When the state of a flag changes (for example, disabled by default to enabled by default), add the change to the version history.
 
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:<feature flag>)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:<feature flag>)
-```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`,
-`<replace with path to>`, and `#anchor-to-section` accordingly.
-
-### Features enabled by project
-
-If the feature can be enabled/disabled for a single project, include in the
-version history note:
+Possible version history entries are:
 
 ```markdown
-> - It can be enabled or disabled for a single project.
+> - [Enabled for GitLab.com](issue-link) in GitLab X.X and is ready for production use.
+> - [Enabled with <flag name> flag](issue-link) for self-managed GitLab in GitLab X.X and is ready for production use.
+> - [Feature flag <flag name> removed](issue-line) in GitLab X.X.
 ```
 
-Then add the by-project code to the code blocks:
+## Feature flag documentation examples
 
-Enable code:
-
-```ruby
-# For the instance
-Feature.enable(:<feature flag>)
-# For a single project
-Feature.enable(:<feature flag>, Project.find(<project id>))
-```
+The following examples show the progression of a feature flag.
 
-Disable code:
+```markdown
+> Introduced in GitLab 13.7.
 
-```ruby
-# For the instance
-Feature.disable(:<feature flag>)
-# For a single project
-Feature.disable(:<feature flag>, Project.find(<project id>))
+NOTE:
+On self-managed GitLab, by default this feature is not available. To make it available,
+ask an administrator to [enable the `forti_token_cloud` flag](../administration/feature_flags.md).`
+The feature is not ready for production use.
 ```
 
-For example, for a feature enabled by default, enabled on GitLab.com, that can
-be enabled by project, and is ready for production use:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), enabled by default.
-> - Enabled on GitLab.com.
-> - Can be enabled or disabled for a single project.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(FREE SELF)**
-
-There can be
-[risks when disabling released features](<replace with path to>/user/feature_flags.md#risks-when-disabling-released-features).
-Refer to this feature's version history for more details.
-
-(...Regular content goes here...)
+If it were to be updated in the future to enable its use in production, you can update the version history:
 
-<!-- Add this at the end of the file -->
-
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
+```markdown
+> - Introduced in GitLab 13.7.
+> - [Enabled with `forti_token_cloud` flag](https://gitlab.com/issue/etc) for self-managed GitLab in GitLab X.X and ready for production use.
 
-```ruby
-# For the instance
-Feature.enable(:<feature flag>)
-# For a single project
-Feature.enable(:<feature flag>, Project.find(<project id>))
+NOTE:
+On self-managed GitLab, by default this feature is available. To hide the feature per user,
+ask an administrator to [disable the `forti_token_cloud` flag](../administration/feature_flags.md).
 ```
 
-To disable it:
+And, when the feature is done and fully available to all users:
 
-```ruby
-# For the instance
-Feature.disable(:<feature flag>)
-# For a single project
-Feature.disable(:<feature flag>, Project.find(<project id>))
+```markdown
+> - Introduced in GitLab 13.7.
+> - [Enabled for GitLab.com](https://gitlab.com/issue/etc) in GitLab X.X and is ready for production use.
+> - [Enabled with `forti_token_cloud` flag](https://gitlab.com/issue/etc) for self-managed GitLab in GitLab X.X and is ready for production use.
+> - [Feature flag `forti_token_cloud`](https://gitlab.com/issue/etc) removed in GitLab X.X.
 ```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`,
-`<replace with path to>`, and `#anchor-to-section` accordingly.
-
-### Features with flag removed
-
-Once the feature is ready and the flag has been removed, clean up the
-documentation. Remove the feature flag mention keeping only a note that
-mentions the flag in the version history notes:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Feature flag removed](link-to-issue) in GitLab 12.2.
-
-(...Regular content...)
-
-````

doc/user/admin_area/monitoring/background_migrations.md

@@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - Recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batched-background-migrations). **(FREE SELF)**
 
-There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
+There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 To update database tables in batches, GitLab can use batched background migrations. These migrations
@@ -54,7 +54,7 @@ Feature.disable(:execute_batched_migrations_on_schedule)
 > - Recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-automatic-batch-size-optimization). **(FREE SELF)**
 
-There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
+There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 To maximize throughput of batched background migrations (in terms of the number of tuples updated per time unit), batch sizes are automatically adjusted based on how long the previous batches took to complete.

doc/user/application_security/dependency_scanning/index.md

@@ -125,7 +125,7 @@ WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
 
 There can be
-[risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 To enable Dependency Scanning in a project, you can create a merge request

doc/user/feature_flags.md

@@ -20,21 +20,13 @@ may be unavailable to you.
 In this case, you'll see a warning like this in the feature documentation:
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 In the version history note, you'll find information on the state of the
 feature flag, including whether the feature is on ("enabled by default") or
 off ("disabled by default") for self-managed GitLab instances and for users of
-GitLab.com. To see the full notes:
-
-1. Click the three-dots icon (ellipsis) to expand version history notes:
-
-   ![Version history note with FF information](img/version_history_notes_collapsed_v13_2.png)
-
-1. Read the version history information:
-
-   ![Version history note with FF information](img/feature_flags_history_note_info_v13_2.png)
+GitLab.com.
 
 If you're a user of a GitLab self-managed instance and you want to try to use a
 disabled feature, you can ask a [GitLab administrator to enable it](../administration/feature_flags.md),
@@ -42,17 +34,3 @@ although changing a feature's default state isn't recommended.
 
 If you're a GitLab.com user and the feature is disabled, be aware that GitLab may
 be working on the feature for potential release in the future.
-
-## Risks when enabling features still in development
-
-Features that are disabled by default may change or be removed without notice in a future version of GitLab.
-
-Data corruption, stability degradation, or performance degradation might occur if
-you enable a feature that's disabled by default. Problems caused by using a default
-disabled feature aren't covered by GitLab support, unless you were directed by GitLab
-to enable the feature.
-
-## Risks when disabling released features
-
-In most cases, the feature flag code is removed in a future version of GitLab.
-If and when that occurs, from that point onward you can't keep the feature in a disabled state.

doc/user/group/iterations/index.md

@@ -41,7 +41,7 @@ In GitLab, iterations are similar to milestones, with a few differences:
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-iteration-cadences). **(PREMIUM SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 Iteration cadences automate some common iteration tasks. They can be used to

doc/user/project/issue_board.md

@@ -233,7 +233,7 @@ and vice versa.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-graphql-based-issue-boards). **(FREE SELF)**
 
 There can be
-[risks when disabling released features](../feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 Using GraphQL-based boards gives you these
@@ -345,7 +345,7 @@ As in other list types, click the trash icon to remove a list.
 > - For GitLab self-managed instances, GitLab administrators can opt to disable the feature flags: [`board_new_list`](#enable-or-disable-new-add-list-form) and [`iteration_board_lists`](#enable-or-disable-iteration-lists-in-boards). **(PREMIUM SELF)**
 
 There can be
-[risks when disabling released features](../feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 You're also able to create lists of an iteration.
@@ -629,7 +629,7 @@ and the target list.
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-multi-selecting-issue-cards). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 You can select multiple issue cards, then drag the group to another position within the list, or to

doc/user/project/merge_requests/changes.md

@@ -140,7 +140,7 @@ Feature.disable(:local_file_reviews)
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-merge-request-conflicts-in-diff). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 To avoid displaying the changes that are already on target branch in the diff,

doc/user/project/merge_requests/commits.md

@@ -42,7 +42,7 @@ Previously merged commits can be added, but they can't be removed due to
 [this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/325538).
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 When reviewing a merge request, it helps to have more context about the changes