Address style team review

- Wording
- Enabled "by project"
- `<replace with path to>`
- Keeping most of the terms "enable/disable" (re previous discussions)

doc/development/documentation/feature_flags.md

 ---
-type: reference
+type: reference, dev
+stage: none
+group: Development
+info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
 description: "GitLab development - how to document features deployed behind feature flags"
 ---
 
@@ -24,6 +27,7 @@ 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).
 
 NOTE: **Note:**
@@ -37,105 +41,120 @@ therefore, it indicates that it cannot be done by regular users of GitLab.com.
 For features disabled by default, if they cannot be used yet due to lack of
 completeness, or if they're still under internal evaluation (for example, for
 performance implications) do **not document them**: add (or merge) the docs
-only when the feature is safe and ready to use and test by end users.
+only when the feature is safe and ready to use and test by end-users.
 
 For feature flags disabled by default, if they can be used by end users:
 
 - Say that it's disabled by default.
 - Say whether it's enabled on GitLab.com.
-- Say whether it can be enabled or disabled per-project.
+- 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.
+- Add a warning to the user saying that the feature is disabled.
 
-For example, for a feature disabled by default, disabled on GitLab.com, can be enabled or disabled per-project, and
-not ready for production use:
+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.
-> - It's deployed behind a feature flag, disabled by default.
+> - It's [deployed behind a feature flag](<replace with path to>/user/feature_flags.md), disabled by default.
 > - It's disabled on GitLab.com.
-> - It's able to be enabled or disabled per-project.
 > - It's not recommended for production use.
 > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#anchor-to-section). **(CORE ONLY)**
 
-(...)
+CAUTION: **Warning:**
+This feature might not be available to you. Check the **version history** note above for details.
+
+(...Regular content goes here...)
+
+<!-- Add this at the end of the file -->
 
 ### Enable or disable <Feature Name> **(CORE ONLY)**
 
 <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](../path/to/administration/feature_flags.md)
-can enable it for your instance. <Feature Name> can be enabled or disabled per-project.
+[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
+can enable it.
 
 To enable it:
 
 ```ruby
-# Instance-wide
 Feature.enable(:<feature flag>)
-# or by project
-Feature.enable(:<feature flag>, Project.find(<project ID>))
 ```
 
 To disable it:
 
 ```ruby
-# Instance-wide
 Feature.disable(:<feature flag>)
-# or by project
-Feature.disable(:<feature flag>, Project.find(<project ID>))
 ```
 ````
 
 Adjust the blurb according to the state of the feature you're documenting.
+Replace `<Feature name>`, `**(CORE ONLY)**`, `<feature flag>`, and
+`<replace with path to>`, and `#anchor-to-section` accordingly.
 
 ### Features that became enabled by default
 
-For 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.
-- Say whether it can be enabled or disabled per-project.
+- 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.
+- 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, that cannot be enabled or disabled per-project, and ready for production use:
+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.
-> - It was deployed behind a feature flag, disabled by default.
+> - It was deployed [deployed behind a feature flag](<replace with path to>/user/feature_flags.md), disabled by default.
 > - [Became enabled by default](link-to-issue) on GitLab 12.1.
 > - It's enabled on GitLab.com.
-> - It's not able to be enabled or disabled per-project.
 > - It's recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(CORE ONLY)**
 
-(...)
+CAUTION: **Warning:**
+This feature might not be available to you. Check the **version history** note above for details.
+
+(...Regular content goes here...)
+
+<!-- Add this at the end of the file -->
 
 ### Enable or disable <Feature Name> **(CORE ONLY)**
 
 <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](..path/to/administration/feature_flags.md)
-can opt to disable it for your instance it cannot be enabled or disabled per-project.
+[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
+can opt to disable it.
 
-To disable it:
+To enable it:
 
 ```ruby
-Feature.disable(:<feature flag>)
+Feature.enable(:<feature flag>)
 ```
 
-To enable it:
+To disable it:
 
 ```ruby
-Feature.enable(:<feature flag>)
+Feature.disable(:<feature flag>)
 ```
 ````
 
 Adjust the blurb according to the state of the feature you're documenting.
+Replace `<Feature name>`, `**(CORE ONLY)**`, `<feature flag>`,
+`<replace with path to>`, and `#anchor-to-section` accordingly.
 
 ### Features directly enabled by default
 
@@ -143,45 +162,134 @@ For features enabled by default:
 
 - Say it's enabled by default.
 - Say whether it's enabled on GitLab.com.
-- Say whether it can be enabled or disabled per-project.
+- 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.
+- Add a warning to the user saying that the feature might be disabled.
 
-For example, for a feature enabled by default, enabled on GitLab.com, cannot be enabled or disabled per-project, and ready for production use:
+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:
 
 ````markdown
 # Feature Name
 
 > - [Introduced](link-to-issue) in GitLab 12.0.
-> - It's deployed behind a feature flag, enabled by default.
+> - It's [deployed behind a feature flag](<replace with path to>/user/feature_flags.md), enabled by default.
 > - It's enabled on GitLab.com.
-> - It's not able to be enabled or disabled per-project.
 > - It's recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(CORE ONLY)**
 
-(...)
+CAUTION: **Warning:**
+This feature might not be available to you. Check the **version history** note above for details.
+
+(...Regular content goes here...)
+
+<!-- Add this at the end of the file -->
 
 ### Enable or disable <Feature Name> **(CORE ONLY)**
 
 <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](..path/to/administration/feature_flags.md)
-can opt to disable it for your instance.
+[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>)
 ```
+````
 
-To enable it:
+Adjust the blurb according to the state of the feature you're documenting.
+Replace `<Feature name>`, `**(CORE ONLY)**`, `<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:
+
+```markdown
+> - It can be enabled or disabled for a single project.
+```
+
+Then add the by-project code to the code blocks:
+
+Enable code:
+
+```ruby
+# For the instance
+Feature.enable(:<feature flag>)
+# For a single project
+Feature.enable(:<feature flag>, Project.find(<project id>))
+```
+
+Disable code:
 
 ```ruby
+# For the instance
+Feature.disable(:<feature flag>)
+# For a single project
+Feature.disable(:<feature flag>, Project.find(<project id>))
+```
+
+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.
+> - It's [deployed behind a feature flag](<replace with path to>/user/feature_flags.md), enabled by default.
+> - It's enabled on GitLab.com.
+> - It can be enabled or disable for a single project.
+> - It's recommended for production use.
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(CORE ONLY)**
+
+CAUTION: **Warning:**
+This feature might not be available to you. Check the **version history** note above for details.
+
+(...Regular content goes here...)
+
+<!-- Add this at the end of the file -->
+
+### Enable or disable <Feature Name> **(CORE ONLY)**
+
+<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 enabled it:
+
+```ruby
+# For the instance
 Feature.enable(:<feature flag>)
+# For a single project
+Feature.enable(:<feature flag>, Project.find(<project id>))
+```
+
+To disable it:
+
+```ruby
+# For the instance
+Feature.disable(:<feature flag>)
+# For a single project
+Feature.disable(:<feature flag>, Project.find(<project id>))
 ```
 ````
 
 Adjust the blurb according to the state of the feature you're documenting.
+Replace `<Feature name>`, `**(CORE ONLY)**`, `<feature flag>`,
+`<replace with path to>`, and `#anchor-to-section` accordingly.
 
 ### Features with flag removed
 
@@ -195,6 +303,6 @@ mentions the flag in the version history notes:
 > - [Introduced](link-to-issue) in GitLab 12.0.
 > - [Feature flag removed](link-to-issue) in GitLab 12.2.
 
-(...)
+(...Regular content...)
 
 ````

doc/development/feature_flags/controls.md

+---
+type: reference, dev
+stage: none
+group: Development
+info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
+---
+
 # Feature flag controls
 
 ## Access

doc/development/feature_flags/development.md

+---
+type: reference, dev
+stage: none
+group: Development
+info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
+---
+
 # Developing with feature flags
 
 This document provides guidelines on how to use feature flags

doc/development/feature_flags/index.md

+---
+type: index, dev
+stage: none
+group: Development
+info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
+---
+
 # Feature flags in development of GitLab
 
 [Feature Flags](../../operations/feature_flags.md)

doc/development/feature_flags/process.md

+---
+type: reference, dev
+stage: none
+group: Development
+info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
+---
+
 # Feature flags process
 
 ## Feature flags for user applications

doc/user/feature_flags.md

+---
+stage: Release
+group: Progressive Delivery
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# GitLab functionality may be limited by feature flags
+
+> Feature flag documentation warnings were [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227806) in GitLab 13.4.
+
+GitLab releases some features in a disabled state using [feature flags](../development/feature_flags/index.md),
+allowing them to be tested by specific groups of users and strategically
+rolled out until they become enabled for everyone.
+
+As a GitLab user, this means that some features included in a GitLab release
+may be unavailable to you.
+
+In this case, you'll see a warning like this in the feature documentation:
+
+CAUTION: **Warning:**
+This feature might not be available to you. Review the **version history** note
+on this page for 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 info](img/version_history_notes_collapsed_v13_2.png)
+
+1. Read the version history information:
+
+   ![Version history note with FF info](img/feature_flags_history_note_info_v13_2.png)
+
+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),
+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.

doc/user/index.md

@@ -151,6 +151,10 @@ requests you're assigned to.
 you have quick access to. You can also gather feedback on them through
 [Discussions](#discussions).
 
+## Features behind feature flags
+
+Understand what [features behind feature flags](feature_flags.md) mean.
+
 ## Keyboard shortcuts
 
 There are many [keyboard shortcuts](shortcuts.md) in GitLab to help you navigate between