blob: 85f6dc38621da4b6891dc4b23ad2060ea4da7225 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
---
info: For assistance with this Style Guide page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects
stage: none
group: unassigned
---
# Documenting Experiment and Beta features
Some features are not generally available and are instead considered
[Experiment or Beta](../../policy/experiment-beta-support.md).
When you document a feature in one of these three statuses:
- Add the tier badge after the page or topic title.
- Do not include `(Experiment)` or `(Beta)` in the left nav.
- Ensure the version history lists the feature's status.
These features are usually behind a feature flag, which follow [these documentation guidelines](feature_flags.md).
If you add details of how users should enroll, or how to contact the team with issues,
the `FLAG:` note should be above these details.
For example:
```markdown
## Great new feature **(EXPERIMENT)**
> [Introduced](link) in GitLab 15.10. This feature is an [Experiment](<link_to>/policy/experiment-beta-support.md).
FLAG:
On self-managed GitLab, by default this feature is not available.
To make it available, an administrator can enable the feature flag named `example_flag`.
On GitLab.com, this feature is not available. This feature is not ready for production use.
Use this great new feature when you need to do this new thing.
This feature is an [Experiment](<link_to>/policy/experiment-beta-support.md). To join
the list of users testing this feature, do this thing. If you find a bug,
[open an issue](link).
```
When the feature is ready for production, remove:
- The text in parentheses.
- Any language about the feature not being ready for production in the body
description.
- The feature flag information if available.
Ensure the version history is up-to-date by adding a note about the production release.
|
