Commit 6f664eae authored by Marcia Ramos's avatar Marcia Ramos

Merge branch '725-update-author-label-inference-docs-and-order' into 'master'

doc: Remove outdated section about group and stage labels

See merge request gitlab-org/gitlab!69282
parents 8c19cfde c66ef17d
...@@ -130,9 +130,9 @@ their color is `#A8D695`. ...@@ -130,9 +130,9 @@ their color is `#A8D695`.
<https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml>, <https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml>,
with `_` replaced with a space. with `_` replaced with a space.
For instance, the "Continuous Integration" group is represented by the For instance, the "Pipeline Execution" group is represented by the
~"group::continuous integration" label in the `gitlab-org` group since its key ~"group::pipeline execution" label in the `gitlab-org` group since its key
under `stages.manage.groups` is `continuous_integration`. under `stages.manage.groups` is `pipeline_execution`.
The current group labels can be found by [searching the labels list for `group::`](https://gitlab.com/groups/gitlab-org/-/labels?search=group::). The current group labels can be found by [searching the labels list for `group::`](https://gitlab.com/groups/gitlab-org/-/labels?search=group::).
...@@ -144,17 +144,6 @@ You can find the groups listed in the [Product Stages, Groups, and Categories](h ...@@ -144,17 +144,6 @@ You can find the groups listed in the [Product Stages, Groups, and Categories](h
We use the term group to map down product requirements from our product stages. We use the term group to map down product requirements from our product stages.
As a team needs some way to collect the work their members are planning to be assigned to, we use the `~group::` labels to do so. As a team needs some way to collect the work their members are planning to be assigned to, we use the `~group::` labels to do so.
Normally there is a 1:1 relationship between Stage labels and Group labels. In
the spirit of "Everyone can contribute", any issue can be picked up by any group,
depending on current priorities. When picking up an issue belonging to a different
group, it should be relabeled. For example, if an issue labeled `~"devops::create"`
and `~"group::knowledge"` is picked up by someone in the Access group of the Plan stage,
the issue should be relabeled as `~"group::access"` while keeping the original
`~"devops::create"` unchanged.
We also use stage and group labels to help measure our [merge request rates](https://about.gitlab.com/handbook/engineering/metrics/#merge-request-rate).
Please read [Stage and Group labels](https://about.gitlab.com/handbook/engineering/metrics/#stage-and-group-labels) for more information on how the labels are used in this context.
### Category labels ### Category labels
From the handbook's From the handbook's
......
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