Commit 0b836c49 authored by Mek Stittri's avatar Mek Stittri

Merge branch 'docs-only-throughput-label' into 'master'

Make documentation a throughput label

See merge request gitlab-org/gitlab!26229
parents 93f07c47 e95ef8d2
......@@ -5,7 +5,8 @@ THROUGHPUT_LABELS = [
'security',
'bug',
'feature',
'backstage'
'backstage',
'documentation'
].freeze
if gitlab.mr_body.size < 5
......
......@@ -40,7 +40,7 @@ scheduling into milestones. Labelling is a task for everyone.
Most issues will have labels for at least one of the following:
- Type: `~feature`, `~bug`, `~backstage`, etc.
- Type: `~feature`, `~bug`, `~backstage`, `~documentation`, etc.
- Stage: `~"devops::plan"`, `~"devops::create"`, etc.
- Group: `~"group::source code"`, `~"group::knowledge"`, `~"group::editor"`, etc.
- Category: `~"Category:Code Analytics"`, `~"Category:DevOps Score"`, `~"Category:Templates"`, etc.
......@@ -70,6 +70,7 @@ The current type labels are:
- ~backstage
- ~"support request"
- ~meta
- ~documentation
A number of type labels have a priority assigned to them, which automatically
makes them float to the top, depending on their importance.
......
......@@ -20,8 +20,7 @@ directly affect the way that any user or administrator interacts with GitLab.
Regardless of the type of issue or merge request, certain labels are required when documentation
is added or updated. The following are added by the issue or merge request author:
- An appropriate [type label](../contributing/issue_workflow.md#type-labels). For example,
`~backstage`.
- An appropriate [type label](../contributing/issue_workflow.md#type-labels).
- The [stage label](../contributing/issue_workflow.md#stage-labels) and
[group label](../contributing/issue_workflow.md#group-labels). For example, `~devops::create` and
`~group::source code`.
......@@ -377,8 +376,10 @@ For complex features split over multiple merge requests:
## For all other documentation
These documentation changes are not associated with the release of a new or updated feature, and are
therefore labeled `backstage` in GitLab, rather than `feature`. They may include:
Documentation changes that are not associated with the release of a new or updated feature
do not take the `~feature` label, but still need the `~documentation` label.
They may include:
- Documentation created or updated to improve accuracy, completeness, ease of use, or any reason
other than a [feature change](#for-a-product-change).
......
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