Make documentation a throughput label

danger/metadata/Dangerfile

@@ -5,7 +5,8 @@ THROUGHPUT_LABELS = [
   'security',
   'bug',
   'feature',
-  'backstage'
+  'backstage',
+  'documentation'
 ].freeze
 
 if gitlab.mr_body.size < 5

doc/development/contributing/issue_workflow.md

@@ -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.

doc/development/documentation/workflow.md

@@ -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).