giseldo/neodataset huggingface dataset:
Setup Search team triage report and make Changzheng Liu, the new EM of Search, a recipient of `group::search` triage report

## Summary

Search team is new. If the triage report has not been setup, please set it up in the bot.

Please make @changzhengliu the recipient of this triage report.

* [ ] Triage packages
   * Group triage packages
* WIP: Infer stage and group labels from subject labels


Story points: 2.0
Adopt merge request pipelines

Following up from https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/325#note_235030694

We need to fully move to merge request pipelines, otherwise some pushes might create confusing two pipelines at the same time!

![Screen_Shot_2019-10-24_at_20.17.46](/uploads/685a3e95090e0085c190716fe06ce4e2/Screen_Shot_2019-10-24_at_20.17.46.png)

On the above screenshot, we can also see the pipelines are out of orders.

Story points: 2.0
Add a way to automatically manage pipeline schedules

We start to have many pipeline schedules so that would be easier to have a script that automatically manages them for us, based on a specification YAML file.

1. Pipeline schedules are specified in a `pipeline-schedules.yml` YAML file
1. Pipeline schedules are synchronized automatically on every `master` commit
1. The same job runs with `--dry-run` on MRs

Story points: 3.0
Notification ping when the number of unique Zendesk or Salesforce links reach a threshold

The step 2 at https://gitlab.com/gitlab-org/quality/triage-ops/issues/156

* Count the number of unique zendesk links in the discussions / comments.
* If 5 and above mention the Engineering Manager and Product Manager for that group.
* If more than 7 and above mention the Dir of Product for that group.
* No need to store any caching we just get a count before adding logic to the notification.

Story points: 3.0
Make priority and severity scoped labels

Per @tipyn in https://gitlab.slack.com/archives/C3JJET4Q6/p1568852155060400

We also have discussed making ~S1 ~S2 .. and ~P1 ~P2 labels scoped before. https://gitlab.com/gitlab-org/gitlab/issues/27906#priorities-and-severities

Right now as teams and groups are getting better at using these labels we should consider changing them to scoped labels so that only one of the labels are present when changing. 

### Priority
* ~P1 to ~"priority::1" 
* ~P2 to ~"priority::2"
* ~P3 to ~"priority::3"
* ~P4 to ~"priority::4"

### Severity
* ~S1 to ~"severity::1"
* ~S2 to ~"severity::2"
* ~S3 to ~"severity::3"
* ~S4 to ~"severity::4"

I believe the next steps are to estimate the work and changes need in all of our systems. Triage automation and charts to reflect this. 

## Steps:

0. [x] `gitlab-org/gitlab` :arrow_right: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39136 and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40280
0. [x] `gitlab-org/release-tools` :arrow_right: https://gitlab.com/gitlab-org/release-tools/-/merge_requests/1151
0. [x] `gitlab-com/www-gitlab-com` :arrow_right: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/59662
0. [x] `gitlab-org/quality/triage-ops` :arrow_right: https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/574
0. [x] `gitlab-org/gitlab-insights` :arrow_right: https://gitlab.com/gitlab-org/gitlab-insights/-/merge_requests/197
0. [x] `gitlab-org/quality/insights-config` :arrow_right: https://gitlab.com/gitlab-org/quality/insights-config/-/merge_requests/13
0. [x] `gitlab-com/gl-infra/incident-management` :arrow_right: https://ops.gitlab.net/gitlab-com/gl-infra/incident-management/-/merge_requests/18
0. [x] `gitlab-com/gl-infra/triage-ops` :arrow_right: https://gitlab.com/gitlab-com/gl-infra/triage-ops/-/merge_requests/43
0. [x] `gitlab-com/gl-infra/production` :arrow_right: https://gitlab.com/gitlab-com/gl-infra/production/-/merge_requests/34
0. [x] (merge around the time we rename) `gitlab-org/quality/triage-serverless` :arrow_right: https://gitlab.com/gitlab-org/quality/triage-serverless/-/merge_requests/29
0. [x] Rename the labels to scoped labels for `gitlab-org` https://gitlab.com/groups/gitlab-org/-/labels?search=P1
0. [x] Rename the labels to scoped labels for `gitlab-com` https://gitlab.com/groups/gitlab-com/-/labels?search=P1
0. [x] (after renamed) `gitlab-org/release-tools` :arrow_right: https://gitlab.com/gitlab-org/release-tools/-/merge_requests/1155

@gl-quality/eng-prod

Story points: 5.0
Add charts/gitlab to milestone/deliverable triage

## Summary

This issue is for requesting triage automation on a given project. Please link to the project needed and select from a list of triage automation rules to be added.

Project: https://gitlab.com/gitlab-org/charts/gitlab

* Automation that does not require an assignee.
  * Rescheduling of milestones (milestone grooming)
  * Labelling ~"missed-deliverable" and `missed:x.y` based on the scheduled milestone.


The Distribution team is slowly working on aligning our process to the rest of the gitlab teams. We aren't ready yet to opt-in to all daily tasks, but we have switched to using the `Deliverable` label, so can now make use of the missed deliverable handling.

I've taken a look, and I think we can use the `move-milestone-forward.yml` and `labels-reminders.yml` policies.

Story points: 2.0
Add gitlab-omnibus to milestone/deliverable triage

## Summary

This issue is for requesting triage automation on a given project. Please link to the project needed and select from a list of triage automation rules to be added.

Project: https://gitlab.com/gitlab-org/omnibus-gitlab/

* Automation that does not require an assignee.
  * Rescheduling of milestones (milestone grooming)
  * Labelling ~"missed-deliverable" and `missed:x.y` based on the scheduled milestone.


The Distribution team is slowly working on aligning our process to the rest of the gitlab teams. We aren't ready yet to opt-in to all daily tasks, but we have switched to using the `Deliverable` label, so can now make use of the missed deliverable handling.

I've taken a look, and I think we can use the `move-milestone-forward.yml` and `labels-reminders.yml` policies.

Story points: 2.0
Rename `roadmaps` to `Category:Roadmaps`, `Category:Agile Portfolio Management` to `Category:Epics`

## Summary

Once https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/29027/diffs is merged, rename `roadmaps` to `Category:Roadmaps`, and `Category:Agile Portfolio Management` to `Category:Epics`.

* ~"roadmaps": [https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name\[\]=roadmaps](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name%5B%5D=roadmaps)
* ~"Category:Agile Portfolio Management": [https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name\[\]=Category%3AAgile%2FPortfolio%2FManagement](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name%5B%5D=Category%3AAgile%2FPortfolio%2FManagement)

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

* [ ] (If applicable) Dashboard creation: create or update the stage/group in https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb.
* [ ] (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) Archive the old label with renaming and adding "DEPRECATED" at the end of the label name.
* [ ] (If applicable) Delete the old dashboard views using the deprecated labels.
* [ ] (If applicable) Update the group triage package definition to use the new label

/cc @gl-quality/eng-prod @kokeefe @johnhope @donaldcook

Story points: 2.0
Rename `search` to `Category:Search`

## Summary

Rename `search` to `Category:Search`.

* ~"search": [https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=search](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name%5B%5D=search)

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

* [ ] (If applicable) Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>.
* [ ] (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) Archive the old label with renaming and adding "DEPRECATED" at the end of the label name.
* [ ] (If applicable) Delete the old dashboard views using the deprecated labels.
* [ ] (If applicable) Update the group triage package definition to use the new label

/cc @gl-quality/eng-prod @phikai @craig-gomes

Story points: 1.0
Growth groups will be renamed

## Summary

Please list the Stage, Group or Category labels changes required. The change can fall under the 3 scenarios below:

* Renaming an existing Stage or Group ~"group::activation" will be `group::acquisition`
* Renaming an existing Stage or Group ~"group::upsell" will be `group::conversion`
* Renaming an existing Stage or Group ~"group::adoption" will be `group::expansion`

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

* [ ] (If applicable) Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>. => https://gitlab.com/gitlab-org/gitlab-insights/merge_requests/163
* [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) Archive the old label with renaming and adding "DEPRECATED" at the end of the label name.~~
* [x] Rename the group labels.
* [x] ~~(If applicable) Delete the old dashboard views using the deprecated labels.~~
* [ ] (If applicable) Update the group triage package definition to use the new label => https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/304

Story points: 2.0
Add exception so the prep/backport MRs for patch releases never have their milestones updated

The milestone was updated by the bot on https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/15885 

```
 🤖 GitLab Bot 🤖 @gitlab-bot changed milestone to %12.3 8 hours ago
🤖 GitLab Bot 🤖 @gitlab-bot added missed:12.2 label 8 hours ago
```

Because these are backport MRs the milestone should stay 12.2, perhaps we should add a new label to identify these MRs since they are special.

We also, potentially have backport MRs that developers open against 12.2 that will be targeting the `12-2-stable[-ee]` branches.

If we could skip anything targeting `MAJOR-MINOR-stable*` that would suffice I think.

Story points: 1.0
`VersionedMilestone#group_milestone` incorrect milestone query when source_id is not a path

Job [#280629926](https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/280629926) failed for c7e8a8da969a3518bf8895b8af800647e2f74284:

Related to changing to using numeric IDs for projects and groups across our rules

Story points: 2.0
Do not fail the schedules if tests won't pass

Now we have two incidents due to changes from www-gitlab-com:

* https://gitlab.com/gitlab-org/quality/triage-ops/issues/253
* https://gitlab.com/gitlab-org/quality/triage-ops/issues/287

I think we need to do something here. Here are a few options:

* Use `webmock` to avoid dependencies on www-gitlab-com
* Remove those backward compatible tests: https://gitlab.com/gitlab-org/quality/triage-ops/issues/253#note_201456403
* Avoid running tests on schedules
* Make tests allow to fail on schedules

@gl-quality/eng-prod Which would you prefer?

Story points: 2.0
Label `missed:x.y` as soon as the milestone expires and not when we close and reschedule issues and MRs

We currently label ~"missed-deliverable" when a milestone expires.

However we do not label them with `~missed:x.y` e.g. ~"missed:12.2" and etc. We only do this after the milestone is closed.

This can cause a short time where an issue detected as ~"missed-deliverable" is re-scheduled by a human manually into the next milestone. This would result in an issue with ~"missed-deliverable" but we cannot pin down which version it was missed. This is likely the cause of the grey undefined missed deliverables.

For example see https://gitlab.com/gitlab-org/gitlab-ce/issues/59754#note_207090158, I had to add ~"missed:12.2" manually. This will get labeled tomorrow since %12.2 is now closed. 

![Screen_Shot_2019-08-22_at_10.56.47_PM](/uploads/a81eac33735476be3bfd64efb102a5a3/Screen_Shot_2019-08-22_at_10.56.47_PM.png)

## Proposal

* Let's label both ~"missed-deliverable" and `missed:x.y` labels together as soon as the milestone expires.


@kwiebers or @markglenfletcher maybe one of you can help take this up? I would like someone other than @godfat to do it to spread the knowledge here.

Please see work that @godfat has done prior, this should be an easy tweak to the triage rules. https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/163/diffs

Also @joshlambert for awareness.

Story points: 2.0
Rename ~"group::serverless and paas" label to ~"group::serverless"

## Summary

Following https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/28665, we will need to rename of ~"group::serverless and paas" label to ~"group::serverless".

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] (If applicable) Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>. => https://gitlab.com/gitlab-org/gitlab-insights/merge_requests/155
* [ ] ~~(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) Archive the old label with renaming and adding "DEPRECATED" at the end of the label name.~~
* [ ] ~~(If applicable) Delete the old dashboard views using the deprecated labels.~~

Story points: 2.0
Rename ~"group::team planning" to ~"group::project management"

## Summary

Following https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/28178/diffs, we will need to rename of ~"group::team planning" to ~"group::project management".

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] (If applicable) Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>.
* [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) Archive the old label with renaming and adding "DEPRECATED" at the end of the label name.
* [x] (If applicable) Delete the old dashboard views using the deprecated labels.

/cc @gl-quality/eng-prod

Story points: 2.0
Fix stage label detection to disallow nested scoped labels

It was brought to my attention that some nested scoped labels starts as a stage label, but then have an additional scoping, e.g. `~devops::release::feature flags` (currently only exists for the `gitlab-ee` project).

We should fix the logic to only detect stage labels matching something like `/\Adevops::\w+\z/`.

Story points: 2.0
Consider using group/project IDs instead of path in jobs and pipeline schedules for better stability

The following discussion from !243 should be addressed:

- [ ] @zj-gitlab started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/243#note_205556529):  (+1 comment)

    > Bit of a nitpick, but I think using project IDs are more stable. For example, I've changed my username to `zj-gitlab` and the old username still gets mentions from bots that work by username instead of ID. Not sure how often we move projects, but could be a potential issue.

I think that's a good suggestion, and I think it would be fine since the project/group name should be present in the job or pipeline schedule. I'll resolve that in a separate issue, thanks!

This is also relevant with the single codebase changes approaching.

Story points: 2.0
Consider cleaning up Ecosystem-specific labels

It seems the Ecosystem group has a lot of labels, even duplicate labels.

## `gitlab-org` Group labels

- ~"group::ecosystem::integrations"
- ~"group::ecosystem::marketplace" 
- ~"group::ecosystem::sdk"

These are categories labels and should follow the `Category::<category name>` convention documented at https://about.gitlab.com/handbook/marketing/website/#category-attributes under `label`.

## `gitlab-org/gitlab-ce` Project labels

- ~"ecosystem::integration" 
- ~"ecosystem::integration::chat" 
- ~"ecosystem::integration::cicd" 
- ~"ecosystem::integration::infra" 
- ~"ecosystem::integration::jenkins" 
- ~"ecosystem::integration::metrics" 
- ~"ecosystem::integration::other" 
- ~"ecosystem::integration::security" 
- ~"ecosystem::integration::workflow"
- ~"ecosystem::integration::marketplace"
- ~"ecosystem::marketplace" duplicates the `gitlab-ce` ~"ecosystem::integration::marketplace" and the `gitlab-org` ~"group::ecosystem::marketplace"
- ~"ecosystem::sdk" duplicates the `gitlab-org` ~"group::ecosystem::sdk"

I'm not in favor of triple-nested scoped labels, and these shouldn't be project-specific labels, but group labels instead (we could just promote them to group labels).

Story points: 2.0
Remove the ~"group::analytics" & ~"devops::manage" labels when they're associated with the ~project, ~"gitlab.com" or ~navigation labels

Hi, 

Can we please move the issues with tags `project`, `gitlab.com` and `navigation` to `group::unallocated`? I think it makes sense to have them with a tag, so that management is aware how many of those are without anyone looking after them (https://gitlab.slack.com/archives/C0NFPSFA8/p1565991373232800). 

cc: @Jeremy, @ebrinkman 

This issue is a follow up of: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/27707#note_203529447 and the series thereof.

Story points: 2.0
Improve community contribution MR discovery and coaching

This was brought up organically by @joshlambert that some of the MRs for ~"devops::verify" from the community are building up. Some of them being almost 1 year. 

> Josh: We have a huge backlog of community contributed MR’s in Verify (specifically Runner) of over 100 (~20% of total). This is proving to be a very frustrating experience, not just contributors but also paying customers: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1041#note_202338266. => Josh: Mek, can we add the backlog of community MR’s to triagebot and quality dashboard? => Mek: We already have a Community Contribution triage package, I‘ll follow up on making improving the format. 

We have community MR triage packages for MRs already https://about.gitlab.com/handbook/engineering/quality/triage-operations/index.html#community-merge-requests-requiring-attention

This seems to only be active for `GitLab CE` & `GitLab EE` I think we should expand this to other core projects e.g.
* [x] Gitaly - https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/29055/edit
* [x] Runner - https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/29680/edit

Other improvements:

* [x] Consider adding ~"Community contribution" to this type of triage report so we can filter on ~"triage-package" and ~"Community contribution" => !260
  * https://gitlab.com/gitlab-org/gitlab-ce/issues/58131
* [x] Spell out the names of these triage reports. Instead of `Merge requests requiring attention` call it `Community Contributions MR report` => !260
* [x] Add a daily report for untriaged 'Community contribution' MRs: https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/592
* [x] Draw attention to EMs for ~"Community contribution" based on a `~group::` label: https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/565 => https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/622
* [ ] Post these Community Triage package on the #mr-coach channel

Story points: 3.0
New policy to move all open issues from `gitlab-org/gitlab-foss` to `gitlab-org/gitlab`

As part of https://gitlab.com/gitlab-org/gitlab-ee/issues/13304, `gitlab-org/gitlab-foss` issue tracker will stay open but we want to automatically move new issues to `gitlab-org/gitlab`.

We should leave an explanation message when doing so, and this should set up as a daily hygiene automation (or even a serverless automation).

Story points: 2.0
Who's the correct PM for the Runner group?

In https://gitlab.com/gitlab-org/quality/triage-ops/blob/a730c493e301bd052e8f54142540ece57d216553/policies/team-triage-package.yml#L1065-1066 the PM for the Runner group is set to @jlenny but in https://about.gitlab.com/handbook/product/categories/#runner-group it's @joshlambert?

What is the correct PM for ~"group::runner"?

Story points: 1.0
Software Composition Analysis group will be renamed to Composition Analysis

## Summary

From https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/26742, ~"group::software composition analysis"  will be renamed to ~"group::composition analysis" 

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] Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>. => https://gitlab.com/gitlab-org/gitlab-insights/merge_requests/150
* [x] No need to migrate anything since the label will be renamed. ~~(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) Archive the old label with renaming and adding "DEPRECATED" at the end of the label name.~~
* [x] Same here, the existing dashboard will just be changed to use the new label name. ~~(If applicable) Delete the old dashboard views using the deprecated labels.~~

/cc @gl-quality/eng-prod

Story points: 2.0