diff options
Diffstat (limited to 'doc/development/documentation/feature_flags.md')
-rw-r--r-- | doc/development/documentation/feature_flags.md | 27 |
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 |