Commit 1ba710a9 authored by Rémy Coutable's avatar Rémy Coutable

Merge branch '340093-update-documentation-type-label-references' into 'master'

Resolve "Update documentation type label references"

See merge request gitlab-org/gitlab!71375
parents 06e5e48e 99e0acc4
......@@ -29,7 +29,7 @@ The extensive usage of feature flags poses a few challenges
We sometimes forget how our feature flags are configured or why we haven't
yet removed the feature flag.
- The usage of feature flags can also be confusing to people outside of
development that might not fully understand dependence of ~feature or ~bug
development that might not fully understand dependence of ~"type::feature" or ~"type::bug"
fix on feature flag and how this feature flag is configured. Or if the feature
should be announced as part of release post.
- Maintaining feature flags poses additional challenge of having to manage
......
......@@ -45,7 +45,7 @@ scheduling into milestones. Labeling is a task for everyone. (For some projects,
Most issues will have labels for at least one of the following:
- Type. For example: `~feature`, `~bug`, `~tooling`, or `~documentation`.
- Type. For example: `~"type::feature"`, `~"type::bug"`, or `~"type::tooling"`.
- Stage. For example: `~"devops::plan"` or `~"devops::create"`.
- Group. For example: `~"group::source code"`, `~"group::knowledge"`, or `~"group::editor"`.
- Category. For example: `~"Category:Code Analytics"`, `~"Category:DevOps Reports"`, or `~"Category:Templates"`.
......@@ -70,12 +70,12 @@ issue should have one and only one.
The current type labels are:
- `~feature`
- `~"type::feature"`
- `~"feature::addition"`
- `~"feature::enhancement"`
- `~"feature::maintenance"`
- `~bug`
- `~tooling`
- `~"type::maintenance"`
- `~"type::bug"`
- `~"type::tooling"`
- `~"tooling::pipelines"`
- `~"tooling::workflow"`
- `~"support request"`
......@@ -342,11 +342,11 @@ To create a feature proposal, open an issue on the
[issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues).
In order to help track the feature proposals, we have created a
[`feature`](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=feature) label.
[`~"type::feature"`](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=type::feature) label.
For the time being, users that are not members of the project cannot add labels.
You can instead ask one of the [core team](https://about.gitlab.com/community/core-team/)
members to add the label `~feature` to the issue or add the following
code snippet right after your description in a new line: `~feature`.
members to add the label `~"type::feature"` to the issue or add the following
code snippet right after your description in a new line: `~"type::feature"`.
Please keep feature proposals as small and simple as possible, complex ones
might be edited to make them small and simple.
......
......@@ -39,7 +39,7 @@ The following are also added by members of the Technical Writing team:
- The `~Technical Writing` [team label](../contributing/issue_workflow.md#team-labels).
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.
do not take the `~"type::feature"` label, but still need the `~documentation` label.
They may include:
......
......@@ -180,7 +180,7 @@ subgraph "CNG-mirror pipeline"
**Additional notes:**
- If the `review-deploy` job keeps failing (and a manual retry didn't help),
please post a message in the `#g_qe_engineering_productivity` channel and/or create a `~"Engineering Productivity"` `~"ep::review apps"` `~bug`
please post a message in the `#g_qe_engineering_productivity` channel and/or create a `~"Engineering Productivity"` `~"ep::review apps"` `~"type::bug"`
issue with a link to your merge request. Note that the deployment failure can
reveal an actual problem introduced in your merge request (i.e. this isn't
necessarily a transient failure)!
......@@ -189,7 +189,7 @@ subgraph "CNG-mirror pipeline"
your merge request. You can also download the artifacts to see screenshots of
the page at the time the failures occurred. If you don't find the cause of the
failure or if it seems unrelated to your change, please post a message in the
`#quality` channel and/or create a ~Quality ~bug issue with a link to your
`#quality` channel and/or create a ~Quality ~"type::bug" issue with a link to your
merge request.
- The manual `review-stop` can be used to
stop a Review App manually, and is also started by GitLab once a merge
......
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