Merge branch 'rw/move-ff-docs-to-handbook' into 'master'

Moving process docs for feature flags to handbook

See merge request gitlab-org/gitlab!55891

.gitlab/issue_templates/Experiment Successful Cleanup.md

@@ -9,10 +9,10 @@ The changes need to become an official part of the product.
 
 - [ ] Determine whether the feature should apply to SaaS and/or self-managed
 - [ ] Determine whether the feature should apply to EE - and which tiers - and/or Core
-- [ ] Determine if tracking should be kept as is, removed, or modified
+- [ ] Determine if tracking should be kept as is, removed, or modified.
 - [ ] Ensure any relevant documentation has been updated.
 - [ ] Consider changes to any `feature_category:` introduced by the experiment if ownership is changing (PM for Growth and PM for the new category as DRIs)
-- [ ] Optional: Migrate experiment to a default enabled [feature flag](https://docs.gitlab.com/ee/development/feature_flags/development.html) for one milestone and add a changelog. Converting to a feature flag can be skipped at the ICs discretion if risk is deemed low with consideration to both SaaS and (if applicable) self managed
+- [ ] Optional: Migrate experiment to a default enabled [feature flag](https://docs.gitlab.com/ee/development/feature_flags) for one milestone and add a changelog. Converting to a feature flag can be skipped at the ICs discretion if risk is deemed low with consideration to both SaaS and (if applicable) self managed
 - [ ] In the next milestone, [remove the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) if applicable
 - [ ] After the flag removal is deployed, [clean up the feature/experiment feature flags](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
 

PROCESS.md

@@ -77,9 +77,9 @@ star, smile, etc.). Some good tips about code reviews can be found in our
 
 ## Feature flags
 
-Overview and details of feature flag processes in development of GitLab itself is described in [feature flags process documentation](https://docs.gitlab.com/ee/development/feature_flags/process.html).
+Overview and details of feature flag processes in development of GitLab itself is described in [feature flags process documentation](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/).
 
-Guides on how to include feature flags in your backend/frontend code while developing GitLab are described in [developing with feature flags documentation](https://docs.gitlab.com/ee/development/feature_flags/development.html).
+Guides on how to include feature flags in your backend/frontend code while developing GitLab are described in [developing with feature flags documentation](https://docs.gitlab.com/ee/development/feature_flags).
 
 Getting access and how to expose the feature to users is detailed in [controlling feature flags documentation](https://docs.gitlab.com/ee/development/feature_flags/controls.html).
 

danger/feature_flag/Dangerfile

 # frozen_string_literal: true
 # rubocop:disable Style/SignalException
 
-SEE_DOC = "See the [feature flag documentation](https://docs.gitlab.com/ee/development/feature_flags/development.html#feature-flag-definition-and-validation)."
+SEE_DOC = "See the [feature flag documentation](https://docs.gitlab.com/ee/development/feature_flags#feature-flag-definition-and-validation)."
 
 SUGGEST_MR_COMMENT = <<~SUGGEST_COMMENT
 ```suggestion

doc/administration/feature_flags.md

@@ -13,7 +13,7 @@ to deploy features in an early stage of development so that they can be
 incrementally rolled out.
 
 Before making them permanently available, features can be deployed behind
-flags for a [number of reasons](../development/feature_flags/index.md#when-to-use-feature-flags), such as:
+flags for a [number of reasons](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#when-to-use-feature-flags), such as:
 
 - To test the feature.
 - To get feedback from users and customers while in an early stage of the development of the feature.

doc/development/api_graphql_styleguide.md

@@ -470,7 +470,7 @@ fails. Consider this when toggling the visibility of the feature on or off on
 production.
 
 The `feature_flag` property does not allow the use of
-[feature gates based on actors](../development/feature_flags/development.md).
+[feature gates based on actors](../development/feature_flags/index.md).
 This means that the feature flag cannot be toggled only for particular
 projects, groups, or users, but instead can only be toggled globally for
 everyone.

doc/development/changelog.md

@@ -57,7 +57,7 @@ the `author` field. GitLab team members **should not**.
 - Any change behind an enabled feature flag **should** have a changelog entry.
 - Any change that adds new usage data metrics and changes that needs to be documented in Product Intelligence [Event Dictionary](https://about.gitlab.com/handbook/product/product-intelligence-guide/#event-dictionary) **should** have a changelog entry.
 - A change that adds snowplow events **should** have a changelog entry -
-- A change that [removes a feature flag](feature_flags/development.md) **must** have a changelog entry.
+- A change that [removes a feature flag](feature_flags/index.md) **must** have a changelog entry.
 - A fix for a regression introduced and then fixed in the same release (i.e.,
   fixing a bug introduced during a monthly release candidate) **should not**
   have a changelog entry.

doc/development/chatops_on_gitlabcom.md

@@ -61,4 +61,4 @@ To request access to ChatOps on GitLab.com:
 
 - [ChatOps Usage](../ci/chatops/index.md)
 - [Understanding EXPLAIN plans](understanding_explain_plans.md)
-- [Feature Groups](feature_flags/development.md#feature-groups)
+- [Feature Groups](feature_flags/index.md#feature-groups)

doc/development/documentation/feature_flags.md

@@ -20,7 +20,7 @@ must be documented. For context, see the
 
 ## Criteria
 
-According to the process of [deploying GitLab features behind feature flags](../feature_flags/process.md):
+According to the process of [deploying GitLab features behind feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle):
 
 > - _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._

doc/development/experiment_guide/index.md

@@ -45,7 +45,7 @@ One is built into GitLab directly and has been around for a while (this is calle
 [`gitlab-experiment`](https://gitlab.com/gitlab-org/gitlab-experiment) and is referred
 to as `Gitlab::Experiment` -- GLEX for short.
 
-Both approaches use [experiment](../feature_flags/development.md#experiment-type)
+Both approaches use [experiment](../feature_flags/index.md#experiment-type)
 feature flags, and there is currently no strong suggestion to use one over the other.
 
 | Feature              | `Experimentation Module` | GLEX |

doc/development/fe_guide/graphql.md

@@ -423,7 +423,7 @@ query getAuthorData($authorNameEnabled: Boolean = false) {
 ```
 
 Then in the Vue (or JavaScript) call to the query we can pass in our feature flag. This feature
-flag needs to be already set up correctly. See the [feature flag documentation](../feature_flags/development.md)
+flag needs to be already set up correctly. See the [feature flag documentation](../feature_flags/index.md)
 for the correct way to do this.
 
 ```javascript

doc/development/feature_flags/controls.md

@@ -36,7 +36,7 @@ easier to measure the impact of both separately.
 
 The GitLab feature library (using
 [Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
-Flags process](process.md) guide) supports rolling out changes to a percentage of
+Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle) guide) supports rolling out changes to a percentage of
 time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md).
 
 For an up to date list of feature flag commands please see [the source
@@ -240,7 +240,7 @@ To disable a feature flag that has been enabled for a specific project you can r
 /chatops run feature set --group=gitlab-org some_feature false
 ```
 
-You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](development.md#selectively-disable-by-actor) the feature flags.
+You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](index.md#selectively-disable-by-actor) the feature flags.
 
 ### Feature flag change logging
 
@@ -281,7 +281,7 @@ To remove a feature flag, open **one merge request** to make the changes. In the
 1. Add the ~"feature flag" label so release managers are aware the changes are hidden behind a feature flag.
 1. If the merge request has to be picked into a stable branch, add the
    appropriate `~"Pick into X.Y"` label, for example `~"Pick into 13.0"`.
-   See [the feature flag process](process.md#including-a-feature-behind-feature-flag-in-the-final-release)
+   See [the feature flag process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#including-a-feature-behind-feature-flag-in-the-final-release)
    for further details.
 1. Remove all references to the feature flag from the codebase, including tests.
 1. Remove the YAML definition for the feature from the repository.

doc/development/merge_request_performance_guidelines.md

@@ -459,7 +459,7 @@ Performance deficiencies should be addressed right away after we merge initial
 changes.
 
 Read more about when and how feature flags should be used in
-[Feature flags in GitLab development](feature_flags/process.md#feature-flags-in-gitlab-development).
+[Feature flags in GitLab development](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#feature-flags-in-gitlab-development).
 
 ## Storage
 

doc/development/new_fe_guide/tips.md

@@ -16,18 +16,18 @@ yarn clean
 
 ## Creating feature flags in development
 
-The process for creating a feature flag is the same as [enabling a feature flag in development](../feature_flags/development.md#enabling-a-feature-flag-locally-in-development).
+The process for creating a feature flag is the same as [enabling a feature flag in development](../feature_flags/index.md#enabling-a-feature-flag-locally-in-development).
 
 Your feature flag can now be:
 
-- [Made available to the frontend](../feature_flags/development.md#frontend) via the `gon`
-- Queried in [tests](../feature_flags/development.md#feature-flags-in-tests)
+- [Made available to the frontend](../feature_flags/index.md#frontend) via the `gon`
+- Queried in [tests](../feature_flags/index.md#feature-flags-in-tests)
 - Queried in HAML templates and Ruby files via the `Feature.enabled?(:my_shiny_new_feature_flag)` method
 
 ### More on feature flags
 
 - [Deleting a feature flag](../../api/features.md#delete-a-feature)
-- [Manage feature flags](../feature_flags/process.md)
+- [Manage feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle)
 - [Feature flags API](../../api/features.md)
 
 ## Running tests locally

doc/development/packages.md

@@ -122,7 +122,7 @@ There are usually 2 phases for the MVC:
 
 When implementing a new package manager, it is tempting to create one large merge request containing all of the
 necessary endpoints and services necessary to support basic usage. Instead, put the
-API endpoints behind a [feature flag](feature_flags/development.md) and
+API endpoints behind a [feature flag](feature_flags/index.md) and
 submit each endpoint or behavior (download, upload, etc) in a different merge request to shorten the review
 process.
 

doc/development/service_measurement.md

@@ -75,7 +75,7 @@ To actually use it, you need to enable measuring for the desired service by enab
 ### Enabling measurement using feature flags
 
 In the following example, the `:gitlab_service_measuring_projects_import_service`
-[feature flag](feature_flags/development.md#enabling-a-feature-flag-locally-in-development) is used to enable the measuring feature
+[feature flag](feature_flags/index.md#enabling-a-feature-flag-locally-in-development) is used to enable the measuring feature
 for `Projects::ImportService`.
 
 From ChatOps:

doc/development/testing_guide/best_practices.md

@@ -545,7 +545,7 @@ end
 
 ### Feature flags in tests
 
-This section was moved to [developing with feature flags](../feature_flags/development.md).
+This section was moved to [developing with feature flags](../feature_flags/index.md).
 
 ### Pristine test environments
 

doc/development/testing_guide/end_to_end/feature_flags.md

@@ -18,8 +18,8 @@ Please be sure to include the tag `:requires_admin` so that the test can be skip
 where admin access is not available.
 
 WARNING:
-You are strongly advised to [enable feature flags only for a group, project, user](../../feature_flags/development.md#feature-actors),
-or [feature group](../../feature_flags/development.md#feature-groups). This makes it possible to
+You are strongly advised to [enable feature flags only for a group, project, user](../../feature_flags/index.md#feature-actors),
+or [feature group](../../feature_flags/index.md#feature-groups). This makes it possible to
 test a feature in a shared environment without affecting other users.
 
 For example, the code below would enable a feature flag named `:feature_flag_name` for the project

doc/development/usage_ping.md

@@ -3,6 +3,5 @@ redirect_to: 'usage_ping/index.md'
 ---
 
 This document was moved to [another location](usage_ping/index.md).
-
 <!-- This redirect file can be deleted after <2021-05-23>. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
\ No newline at end of file

doc/development/usage_ping/index.md

@@ -947,7 +947,7 @@ Each aggregate definition includes following parts:
   relay on the same data source. Additional data source requirements are described in the
   [Database sourced aggregated metrics](#database-sourced-aggregated-metrics) and
   [Redis sourced aggregated metrics](#redis-sourced-aggregated-metrics) sections.
-- `feature_flag`: Name of [development feature flag](../feature_flags/development.md#development-type)
+- `feature_flag`: Name of [development feature flag](../feature_flags/index.md#development-type)
   that is checked before metrics aggregation is performed. Corresponding feature flag
   should have `default_enabled` attribute set to `false`. The `feature_flag` attribute
   is optional and can be omitted. When `feature_flag` is missing, no feature flag is checked.

doc/user/analytics/index.md

@@ -61,6 +61,6 @@ The following analytics features are available at the project level:
 - [Insights](../project/insights/index.md). **(ULTIMATE)**
 - [Issue](../group/issues_analytics/index.md). **(PREMIUM)**
 - [Merge Request](merge_request_analytics.md), enabled with the `project_merge_request_analytics`
-  [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-locally-in-development). **(PREMIUM)**
+  [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development). **(PREMIUM)**
 - [Repository](repository_analytics.md). **(FREE)**
 - [Value Stream](value_stream_analytics.md). **(FREE)**

doc/user/group/index.md

@@ -242,7 +242,7 @@ a [beta feature](https://about.gitlab.com/handbook/product/#beta).
 
 For a group, you can view how many merge requests, issues, and members were created in the last 90 days.
 
-These Group Activity Analytics can be enabled with the `group_activity_analytics` [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-locally-in-development).
+These Group Activity Analytics can be enabled with the `group_activity_analytics` [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development).
 
 ![Recent Group Activity](img/group_activity_analytics_v13_10.png)