Update issue workflow with new scoped type labels

Signed-off-by: Rémy Coutable <remy@rymai.me>

doc/architecture/blueprints/feature_flags_development/index.md

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

doc/development/contributing/issue_workflow.md

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

doc/development/documentation/workflow.md

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

doc/development/testing_guide/review_apps.md

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