summaryrefslogtreecommitdiff
path: root/doc/development/documentation/feature_flags.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/development/documentation/feature_flags.md')
-rw-r--r--doc/development/documentation/feature_flags.md27
1 files changed, 13 insertions, 14 deletions
diff --git a/doc/development/documentation/feature_flags.md b/doc/development/documentation/feature_flags.md
index 3d71a180087..010058350ba 100644
--- a/doc/development/documentation/feature_flags.md
+++ b/doc/development/documentation/feature_flags.md
@@ -7,11 +7,11 @@ 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
-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**
-accordingly.
+GitLab uses [feature flags](../feature_flags/index.md) to roll
+out the deployment of its own features.
+
+When the state of a feature flag changes, the developer who made the change
+**must update the documentation**.
## When to document features behind a feature flag
@@ -19,21 +19,20 @@ Every feature introduced to the codebase, even if it's behind a disabled feature
must be documented. For more information, see
[the discussion that led to this decision](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47917#note_459984428).
-When the feature is [implemented over multiple merge requests](../feature_flags/index.md#feature-flags-in-gitlab-development),
-discuss the exact documentation plan with your technical writer. Consider
-creating a dedicated documentation issue if the feature:
+When the feature is [implemented in multiple merge requests](../feature_flags/index.md#feature-flags-in-gitlab-development),
+discuss the plan with your technical writer.
+
+You can create a documentation issue and delay the documentation if the feature:
- Is far-reaching (makes changes across many areas of GitLab), like navigation changes.
- Includes many MRs.
- Affects more than a few documentation pages.
- Is not fully functional if the feature flag is enabled for testing.
-If you and the technical writer agree to delay the product documentation (for example, until after testing),
-collaborate with the TW to create a documentation issue detailing the plan for adding the content.
-The PM and EM should be included in the discussions to make sure the task of adding the documentation is assigned and scheduled.
-Despite any planned delays, every feature flag in the codebase is automatically listed at
-<https://docs.gitlab.com/ee/user/feature_flags.html#available-feature-flags>,
-even when the feature is not fully functional.
+The PM, EM, and writer should make sure the documentation work is assigned and scheduled.
+
+Every feature flag in the codebase is [in the documentation](../../user/feature_flags.md),
+even when the feature is not fully functional or otherwise documented.
## How to add feature flag documentation