giseldo/neodataset huggingface dataset:
Remove automatic addition of the Category:Templates label

## Summary

There appears to be automation that sets label `Category:Templates` for any new issue in `https://gitlab.com/gitlab-org/project-templates`. This automation needs to be removed, as `Category:Templates` no longer exists. Any other automation based on the `Category:Templates` label should also be removed.

### Action items

* [x] Link the merge request to www-gitlab-com for the [category.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml) change: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/86626
* [ ] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
* [ ] (If applicable) Rename the old label by adding `[DEPRECATED]` at the end of the label name, like ~"CI/CD [DEPRECATED]".


/cc @gl-quality/eng-prod

Story points: 1.0
Discrepancy between  Issue / issue count between the Quality Heat map and the actual issue list

#### Problem:

The discrepancy was noticed in the most recent Triage issue - https://gitlab.com/gitlab-org/quality/triage-reports/-/issues/3911 (2021-07-19) 

Discussion - https://gitlab.com/gitlab-org/quality/triage-reports/-/issues/3911#note_630403592

In the [Heat map for triage failures](https://gitlab.com/gitlab-org/quality/triage-reports/-/issues/3911#heatmap-for-triage-failures), clicking on [157 issues under No severity, No priority](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name%5B%5D=Quality&label_name%5B%5D=QA&not%5Blabel_name%5D%5B%5D=priority%3A%3A1&not%5Blabel_name%5D%5B%5D=priority%3A%3A2&not%5Blabel_name%5D%5B%5D=priority%3A%3A3&not%5Blabel_name%5D%5B%5D=priority%3A%3A4&not%5Blabel_name%5D%5B%5D=severity%3A%3A1&not%5Blabel_name%5D%5B%5D=severity%3A%3A2&not%5Blabel_name%5D%5B%5D=severity%3A%3A3&not%5Blabel_name%5D%5B%5D=severity%3A%3A4) section lists out ~ 1666 Open issues which includes triage reports, test sessions, etc. 
![Screen_Shot_2021-07-19_at_6.01.12_PM](/uploads/68882f2c12c2100968cae9a030997cdf/Screen_Shot_2021-07-19_at_6.01.12_PM.png)

#### Expected behaviour:
The issue list should display the same number of Open issues that was shown in the Heat Map.

#### Actual behaviour:
The issue list displayed ~1666 Open issues rather than 157 as shown in the Heat Map.
![Screen_Shot_2021-07-19_at_6.03.18_PM](/uploads/8a936e037b161e4b670da953d87e3ff3/Screen_Shot_2021-07-19_at_6.03.18_PM.png)

#### Potential ROot cause/ Solution:

```
Kyle Wiebers @kwiebers · 1 hour ago
Owner
I think this is due to that table having the .only-gitlab filter applied for the role but the policy is run at the gitlab-org group level so the links in the heatmap go to the group but the counts are for the project.
```

Story points: 3.0
Move monthly EM bugs/performance issues triage into this project

A monthly job runs in the Plan project (https://gitlab.com/gitlab-org/plan/) that generates triage issues for EMs in Plan and Create which make it easier to include bugs and performance issues in the release post.

* Job definitions: [.gitlab-ci.yml](https://gitlab.com/gitlab-org/plan/-/blob/master/.gitlab-ci.yml)
* Schedule: [`0 14 13 * *`](https://gitlab.com/gitlab-org/plan/-/pipeline_schedules)
* Policies: https://gitlab.com/gitlab-org/plan/-/tree/master/policies
* Example issues: [Plan bugs for 14.0](https://gitlab.com/gitlab-org/plan/-/issues/342), [Create performance issues for 13.12](https://gitlab.com/gitlab-org/create-stage/-/issues/12853)

A stage-level report is generated that makes it easy for EMs to collaborate by providing a checklist with each item to be triaged, along with a markdown list that can be copied into a commit on the corresponding MR. 

This job has a number of downsides that would benefit from its being moved into this project:

- The creation of the issues in pipelines fails because they trigger spam detection, so they have to be manually copied from artifacts into issues;
- Maintenance is within the Plan project and is somewhat opaque to other teams.

The current implementation also has the following drawbacks:

- DRIs are frequently out of date as the SSoT is different from https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/group-definition.yml;
- Code is not DRY, each policy is replicated including issue description text. Expanding to other stages requires duplicating policies in full each time;
- Current milestone isn't usable in title or description.

### Proposal

Move this monthly triage into this project, allowlisting it to Plan and Create only to begin with. Then gradually add stages as they show an interest.

The following steps could be used:

- [x] Align the current policies as closely as possible with this project's
   - [x] Remove legacy Ruby script and jobs https://gitlab.com/gitlab-org/plan/-/merge_requests/43
   - [x] Copy the `group-definition.yml` file into the project
   - [x] Refactor policies to use `group-definition.yml` as the SSoT for EMs and Groups
- [x] Make a single policy for each triage issue type (bugs and performance issues) that consumes the `group-definition.yml`
- [x] Move the triage into this project 
- [x] Remove jobs and clean up the Plan project https://gitlab.com/gitlab-org/plan/-/merge_requests/51

Story points: 2.0
Update labels to reflect two merged groups

Recently ~"group::dynamic analysis" and ~"group::fuzz testing" merged, and kept the name ~"group::dynamic analysis". This organizational change is reflected in this MR, https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/79866

We need to determine how to handle the ~"group::fuzz testing" label. It is still intermittently being used by customers and team members. It is also has issues associated with it that have been closed. 

Whatever updates need to be made should be reflected in the handbook:
https://about.gitlab.com/handbook/product/product-processes/#creating-new-groups

Story points: 3.0
Category:Experimentation split into four new categories

## Summary

The existing `Category:Experimentation` can be removed. There are four new categories added, with changes to features.yml and categories.yml

- https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=Category%3AAdoption%20Experiment
- https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=Category%3AActivation%20Experiment
- https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=Category%3AConversion%20Experiment
- https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=Category%3AExpansion%20Experiment

The original `Category:Experimentation` label has not been removed yet, but has been `[DEPRECATED]`

- https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=Category%3AExperimentation

I manually migrated the issues and MRs (there were no Epics with this label).

### Action items

* [x] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/80937
* [x] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
* [x] (If applicable) Rename the old label by adding `[DEPRECATED]` at the end of the label name, like ~"CI/CD [DEPRECATED]".
* [ ] Disable the inference for all single-category labels under ~"devops::growth".

#### Background

- issues:
  - https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/656
  - https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1008
- related MRs:
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/75987
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/80837
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/80937
  

/cc @gl-quality/eng-prod

Story points: 1.0
Treat non-scoped group label as a group label

Spinning off from https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/631#note_480174901

Instead of treating non-scoped group label a special case, we can just treat them the same. This means whenever there's a non-scoped group label (e.g. ~"group:certify"), we do not need to infer another group label.

This way, when there's ~"group:certify" we can still infer categories for it, and also make it possible to infer that from the categories. This will also require https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/71331 to specify which exact label we need to use for the group label.

With this we can fully resolve https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/631

For now we're just working around it by silencing it when ~"group:certify" is added.

Story points: 2.0
Consider retiring the "Community contributions merge request report" issue

Now that:

1. We automatically label community contributions with ~"Community contribution" (with `triage-serverless`): https://gitlab.com/gitlab-org/quality/triage-serverless/-/blob/987f8db13d1741b2df08d901fb660fcb137afc6e/triage/processor/thank_community_contribution.rb#L34
1. ~"Community contribution" are triaged so that they have a group label set: https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/stages/report/untriaged-community-merge-requests.yml
1. ~"Community contribution" are surfaced per group in the "Merge requests requiring attention for <group>" report: https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/006cb0be0bac79b0435d9132cfb5ff6e3456d53b/policies/template/merge-requests-needing-attention.yml.erb#L79-107

The "Community contributions merge request report" issue isn't useful (e.g. https://gitlab.com/gitlab-org/gitlab/-/issues/249036) and should probably be retired. It seems to only include MRs opened by former team members (hence which don't have the ~"Community contribution" label set).

Story points: 1.0
Label `group::provision` doesn't exist

# Error Details:
- Sentry event: https://sentry.gitlab.net/gitlab/triage-ops/issues/2441732
- First seen: 
2021-01-12T00:06:27+00:00
- Last seen: 2021-01-12T00:08:10+00:00
 - Events: 3
- Users: 0

```

bundler: failed to load command: gitlab-triage (/usr/local/bundle/bin/gitlab-triage)
/usr/local/bundle/gems/gitlab-triage-1.14.3/lib/gitlab/triage/command_builders/label_command_builder.rb:20:in `block in ensure_labels_exist!': Label `group::provision` doesn't exist! (Gitlab::Triage::Resource::Label::LabelDoesntExistError)
	from /usr/local/bundle/gems/gitlab-triage-1.14.3/lib/gitlab/triage/command_builders/label_command_builder.rb:16:in `each'
	from /usr/local/bundle/gems/gitlab-triage-1.14.3/lib/gitlab/triage/command_builders/label_command_builder.rb:16:in `ensure_labels_exist!'
	from /usr/local/bundle/gems/gitlab-triage-1.14.3/lib/gitlab/triage/command_builders/label_command_builder.rb:8:in `build_command'
	from /usr/local/bundle/gems/gitlab-triage-1.14.3/lib/gitlab/triage/action/comment.rb:44:in `build_comment'
	from /usr/local/bundle/gems/gitlab-triage-1.14.3/lib/gitlab/triage/action/comment.rb:32:in `block in act'
	from /usr/local/lib/ruby/2.6.0/delegate.rb:83:in `each'
```

Story points: 1.0
Allow contributors to ping the gitlab-bot for adding a type label

Following triage-serverless#52 and triage-serverless#63, we should allow contributors to add a type label to a MR with a syntax like `@gitlab-bot label ~"type::bug"`.

- Only the author of the issuable will be able to request labelling.
- Only a group or type label can be requested for now.
- Rate limiting is set to 60 label commands per author per hour.

Story points: 2.0
Job Failed #850788746

Job [#850788746](https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/850788746) failed for 286fdff9d2e8c5f7e3b01aaa412d4fcbe3c204f7:

```
  1) DevopsLabels DevopsLabels::Context#new_stage_and_group_labels_from_intelligent_inference and #comment_for_intelligent_stage_and_group_labels_inference stage: no, group: yes, category: no, team: no => Stage label based on group returns a comment with a /label quick action
     Failure/Error: expect(resource.comment_for_intelligent_stage_and_group_labels_inference).to eq %(#{explanation}\n#{label_action})
       expected: "Setting label(s) ~\"devops::enablement\" ~\"section::enablement\" based on ~\"group::memory\".\n/label ~\"devops::enablement\" ~\"section::enablement\""
            got: "Setting label(s) ~\"Category:Memory\" ~\"devops::enablement\" ~\"section::enablement\" based on ~\"group::memory\".\n/label ~\"Category:Memory\" ~\"devops::enablement\" ~\"section::enablement\""
       (compared using ==)
       Diff:
       @@ -1,3 +1,3 @@
       -Setting label(s) ~"devops::enablement" ~"section::enablement" based on ~"group::memory".
       -/label ~"devops::enablement" ~"section::enablement"
       +Setting label(s) ~"Category:Memory" ~"devops::enablement" ~"section::enablement" based on ~"group::memory".
       +/label ~"Category:Memory" ~"devops::enablement" ~"section::enablement"
     # ./spec/lib/devops_labels_spec.rb:837:in `block (5 levels) in <top (required)>'
```

Story points: 1.0
Deprecate Category:Alert Management label

## Summary

**We need to deprecate the ~"Category:Alert Management" label. This category is getting removed from categories.yml. All issues with this label can be moved to ~"Category:Incident Management"**

This template is for new or renaming Category labels. This review helps to ensure there will be no impact with triage automation and reports.

### Action items

* [x] Link the merge request to www-gitlab-com for the [category.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml) change: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/67449
* [x] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
* [ ] (If applicable) Rename the old label by adding `[DEPRECATED]` at the end of the label name, like ~"CI/CD [DEPRECATED]".


/cc @gl-quality/eng-prod

Story points: 2.0
Ensure issues for current milestone have a tier label

## Overview
To specify the tier of a new feature, Product will typically apply a label to issues specifying the license tier of the feature (e.g. `GitLab Premium`). However, we periodically may forget to apply this label consistently, which can also lead to [confusion at times](https://gitlab.com/gitlab-com/Product/-/issues/1669).

I've definitely done this - the problem isn't that I applied the incorrect label, but that I neglected to apply it at all in the midst of creating multiple issues. In order to prevent this, we should make sure that issues with the current milestone (e.g. issues that are being worked on) have a tiering label so we're being intentional about which tier a feature belongs in.

## Proposal
Set up a triage policy:
* If an issue is scheduled for the current milestone AND has a `group::` label AND has a ~direction label AND does not have one of ~"GitLab Core", ~"GitLab Starter", ~"GitLab Premium" , or ~"GitLab Ultimate"
* Then leave a comment in the issue and @ mention the relevant PM to add an appropriate tier label.

Story points: 1.0
Rename 'value stream management' group to 'optimize'

Handbook update: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/66633/diffs

For every case above, the Engineering Productivity team needs to ensure that:

* The label change is factored into the triage mechanism.
* Engineering Dashboards at https://quality-dashboard.gitlap.com/groups/gitlab-org are updated.
* Old labels are migrated correctly on affected issues and merge requests.

### Action items

* [x] Rename ~"group::value stream management" to ~"group::optimize"
* [x] Rename ~"Category:Value Stream Analytics" to ~"Category:Value Stream Management"
* [x] Update the group triage report definition to use the new label: https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/674
* [x] Update the group label's description to refer to the new Stage.
* [x] Rename ~"group::analytics" to ~"group::optimize" in Periscope: https://gitlab.com/gitlab-data/periscope/-/merge_requests/78

Story points: 2.0
Rename group::acquisition to group::activation

## Summary

Tracking issue: https://gitlab.com/gitlab-org/growth/team-tasks/-/issues/230

* Renaming an existing Stage or Group

~"group::acquisition" is becoming ~"group::activation" due to a change in Growth KPIs:

* https://about.gitlab.com/handbook/product/performance-indicators/#new-group-namespace-create-stage-adoption-rate
* https://about.gitlab.com/direction/growth/#growth-kpi
* https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/66124/diffs#ded7bbea02ff2128954ee2b752d088426082101b_176_174 (not a direct line-for-line match)

For every case above, the Engineering Productivity team needs to ensure that:

* The label change is factored into the triage mechanism.
* Engineering Dashboards at <https://quality-dashboard.gitlap.com/groups/gitlab-org> are updated.
* Old labels are migrated correctly on affected issues and merge requests.

### Action items

* [x] Rename ~"group::acquisition" to ~"group::activation"
* [x] Update the group triage report definition to use the new label: https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/668
* [x] Update the group label's description to refer to the new Stage.
* [x] Rename ~"group::acquisition" to ~"group::activation" in Periscope: https://gitlab.com/gitlab-data/periscope/-/merge_requests/77

/cc @gl-quality/eng-prod @jstava

Story points: 2.0
Rename group::retention to group::adoption

## Summary

* Renaming an existing Stage or Group

~"group::retention" is becoming ~"group::adoption" due to a change in Growth KPIs:

* https://about.gitlab.com/handbook/product/performance-indicators/#new-group-namespace-create-stage-adoption-rate
* https://about.gitlab.com/direction/growth/#growth-kpi
* https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/66124/diffs#ded7bbea02ff2128954ee2b752d088426082101b_176_173 (not a direct line-for-line match)

**Note** this new group label has been created and is being used.

https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aadoption


For every case above, the Engineering Productivity team needs to ensure that:

* The label change is factored into the triage mechanism.
* Engineering Dashboards at <https://quality-dashboard.gitlap.com/groups/gitlab-org> are updated.
* Old labels are migrated correctly on affected issues and merge requests.

### Action items

* [x] Add ~"group::retention" to all issues/MRs with ~"group::adoption"
  * [x] Remove the ~"group::adoption" label
  * [x] Rename ~"group::retention" to ~"group::adoption"
* [x] Update the group triage report definition to use the new label: https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/669
* [x] Update the group label's description to refer to the new Stage.
* [x] Rename ~"group::retention" to ~"group::adoption" in Periscope: https://gitlab.com/gitlab-data/periscope/-/merge_requests/79

/cc @gl-quality/eng-prod @mkarampalas

Story points: 2.0
Rename 'analytics' group to 'value stream management'

## Summary

Handbook update: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/65811

For every case above, the Engineering Productivity team needs to ensure that:

* The label change is factored into the triage mechanism.
* Engineering Dashboards at <https://quality-dashboard.gitlap.com/groups/gitlab-org> are updated.
* Old labels are migrated correctly on affected issues and merge requests.

### Action items

* [x] Rename ~"group::analytics" to ~"group::value stream management"
* [x] Rename ~"Category:Value Stream Management" to ~"Category:Value Stream Analytics"
* [x] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
  * [x] Merge ~"value stream analytics" into ~"Category:Value Stream Analytics": https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/663
  * [ ] Check if label migration will apply labels which have subscribers.
    [Communicate with the subscribers](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#communicate-early-and-broadly-about-expected-automation-impact)
    before applying the label migration.
* [x] Update the group triage report definition to use the new label: https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/662
* [x] Update the group label's description to refer to the new Stage.
* [ ] Rename ~"group::analytics" to ~"group::value stream management" in Periscope: https://gitlab.com/gitlab-data/periscope/-/merge_requests/75

Story points: 3.0
Fulfillment Section Rollout

## Description

Fulfillment is moving to its own section with https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/62755 and I'm unsure of the implications we need to consider

## Tasks

- [x] Create ~"section::fulfillment", ~"devops::fulfillment", ~"group::purchase", ~"group::provision", ~"Category:Purchase", and ~"Category:Provision" `gitlab-org` group labels
- [x] Consider changes to the Embedded Team Dashboard for [UX](https://app.periscopedata.com/app/gitlab/736036/UX-Embedded-Dashboard) and [Quality](https://app.periscopedata.com/app/gitlab/736012/Quality-Embedded-Dashboard)
- [x] Update [`group-definition.yml`](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/group-definition.yml) and generate corresponding policies and jobs => https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/643

### Migration => https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/639

1. [x] Rename \~"group::fulfillment" to ~"devops::fulfillment"
1. [x] Migrate current ~"devops::fulfillment" + ~frontend issues/MRs to ~"section::fulfillment" + ~"group::purchase" - ~"section::growth" - ~"devops::growth" in `gitlab-org/gitlab`: https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/769726383
   - Expected updates: 78 issues, 100 MRs
1. [x] [**To be confirmed**] Migrate current ~"devops::fulfillment" issues/MRs to ~"section::fulfillment" + ~"group::provision" - ~"section::growth" - ~"devops::growth" in `gitlab-org/customers-gitlab-com`: https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/769726383
   - Expected updates: 1782 issues, 1775 MRs
1. [x] Migrate current ~"devops::fulfillment" issues/MRs to ~"section::fulfillment" + ~"group::provision" - ~"section::growth" - ~"devops::growth" in `gitlab-org/license-gitlab-com`: https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/769726387
   - Expected updates: 110 issues, 76 MRs

### Potential migration

1. [x] Migrate ~"Category:Billing" [794 issues](https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=Category%3ABilling), [65 MRs](https://gitlab.com/groups/gitlab-org/-/merge_requests?label_name%5B%5D=Category%3ABilling), and [14 epics](https://gitlab.com/groups/gitlab-org/-/epics?label_name%5B%5D=Category%3ABilling) to ~"Category:Purchase" / ~"Category:Provision"?

Story points: 3.0