Skip to content

G
gitlab-ce
Commit c00d6a18 authored by Suzanne Selhorn's avatar Suzanne Selhorn Committed by Craig Norris
Browse files
Options

Updated feature flag documentation guidance

parent b4f5847a
Hide whitespace changes
Inline Side-by-side
Showing with 88 additions and 310 deletions
doc/administration/feature_flags.md
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
View file @ c00d6a18
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7