giseldo/neodataset huggingface dataset:
Search group will be part of enablement

## Summary

~group::search will be created under ~"devops::enablement" https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/27493#note_201799245

All search features and `~category::` will be moved here as well. 

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] Triage automation: create or update the stage/group/categories in <https://gitlab.com/gitlab-org/quality/triage-ops/blob/master/lib/devops_labels.rb>.
* [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/149
* [ ] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests. - https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/246
* [ ] ~~(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.~~

/cc @phikai 
/cc @gl-quality/eng-prod

Story points: 3.0
Default Group Label for Specific Projects

## Proposal 

Add new policies for each project that will be scheduled and run prior to the daily label inference policy.

## Background and Research

@phikai reported that Issues that were labeled with ~search had the ~"devops::create" and ~"group::editor" labels applied by GitLab Bot. 

The impacted issues look to be issues without a group label present and have a matching category label which will be used to infer the stage and group label. Examples looking at ~search :

- https://gitlab.com/gitlab-org/gitter/webapp/issues/1510
- https://gitlab.com/gitlab-org/gitlab-docs/issues/167
- https://gitlab.com/gitlab-org/gitter/webapp/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=search
- https://gitlab.com/gitlab-org/gitlab-docs/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=search

While I was looking at the examples in the searches, it seemed that there was not a group label on the impacted issues. On an ongoing basis, there will be a comment informing why the labels were inferred but we disabled that for the bulk runs in https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/199/pipelines

@markglenfletcher had the idea to default group labels for certain projects. Here's some of the mappings from the groups he identified if we want to go that route. 
- [Gitaly](https://gitlab.com/gitlab-org/gitaly) - ~"group::gitaly" 
- [Runner](https://gitlab.com/gitlab-org/gitlab-runner) - ~"group::runner" 
- [Gitter](https://gitlab.com/gitlab-org/gitter) - ~"group::gitter" 
- [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab) - ~"group::distribution" 
- [GitLab CNG](https://gitlab.com/gitlab-org/build/CNG) - ~"group::distribution" 

There is likely more that I'm missing but I started with what I could find and felt confident in :smile: 

Story points: 2.0
Deprecate the legacy team labels

## Summary

We will deprecate the following legacy team labels according to the new rollout plan at https://gitlab.com/gitlab-org/quality/triage-ops/issues/172#rollout-steps by adding a ` [DEPRECATED]` suffix to them:

- [x] ~Manage
- [x] ~Plan
- [x] ~Create
- [x] ~Verify
- [x] ~Package
- [x] ~Release
- [x] ~Configure
- [x] ~Serverless
- [x] ~Monitor
- [x] ~Secure
- [x] ~Defend
- [x] ~Growth
- [x] ~Gitaly
- [x] ~Gitter
- [x] ~Distribution
- [x] ~Geo
- [x] ~Memory
- [x] ~Ecosystem

Groups should be using exclusively their group and stage labels from now on.

## Action items

### On 2019-08-13

- [x] Announce the deprecation on the company call, `#development`, `#product`, and Engineering Week in Review.

>>>
On 2019-08-19, we will deprecate the team labels by adding a ` [DEPRECATED]` suffix to them (https://gitlab.com/gitlab-org/quality/triage-ops/issues/254). Please use the Stage (`devops::xxx`) and Group (`group::xxx`) labels instead.

- This is part of an effort to transition from team labels to stage & group labels: https://gitlab.com/gitlab-org/quality/triage-ops/issues/172#note_201666990
- We are tackling the remaining edge cases where more than one legacy team labels exists after this https://gitlab.com/gitlab-org/quality/triage-ops/issues/242.
>>>

### Before 2019-08-19

- [x] Triage automation: create or update the stage/group/categories in <https://gitlab.com/gitlab-org/quality/triage-ops/blob/master/lib/devops_labels.rb>. => https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/255
- [x] Dashboard creation: update the teams in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>. => https://gitlab.com/gitlab-org/gitlab-insights/merge_requests/151
- [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] The native Insights configuration
- [x] The Periscope dashboards
- [x] Update https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/issue_workflow.md => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31811

### On 2019-08-19

- [x] Archive the old labels with renaming and adding "DEPRECATED" at the end of the label names.
- [x] ~~(If applicable) Delete the old dashboard views using the deprecated labels.~~

Story points: 3.0
A breaking API change broke the `policies/label-accepting-merge-requests.yml` policy

A breaking change to the Issues and MRs API was introduced and reported in https://gitlab.com/gitlab-org/gitlab-ce/issues/65676.

This in turn made our `policies/label-accepting-merge-requests.yml` policy apply the ~"Accepting merge requests" to a lot of issues that don't have a milestone, where normally they shouldn't (as we target issues with a milestone only).

A fix is in preparation to prevent that from happening while the API issue is fixed and deployed, and to revert the mistakenly added labels: https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/233

Story points: 2.0
Consolidate more labels for marking issues that are open for community contributions

### Problem

Following the changes in https://gitlab.com/gitlab-org/quality/triage-ops/issues/179, there are three more label variants for marking issues that are open for community contributions. These include:

1. **7 issues** with ~"Accepting Merge Requests" project label used in the [`gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse) project.
2. **2 issues** with ~"accepting merge requests" project label used in the [`gitlab-mattermost`](https://gitlab.com/gitlab-org/gitlab-mattermost) project.
3. **3 issues** with ~"accepting MR" project label used in the [`cookbook-gitlab`](https://gitlab.com/gitlab-org/cookbook-gitlab) project.

The issues affected are very few but this can cause some confusion during issue search.

![Screenshot_2019-08-06_at_01.24.26](/uploads/5586a43046937e826363a4f5e56dabea/Screenshot_2019-08-06_at_01.24.26.png)

### Proposal

Let's remove these three project labels and replace them on all attached issues with the group label ~"Accepting merge requests".

Story points: 1.0
Remove association between `gitlab.com` label and Manage/Analytics

## Overview

GitLab Bot appears to apply ~"devops::manage" and ~"group::analytics" (or possibly Measure) to issues associated with the ~"gitlab.com" label. This isn't as helpful as we'd like, since ~"gitlab.com" issues span more than just Manage issues - see https://gitlab.com/gitlab-org/gitlab-ce/issues/62052 for an example.

## Proposal

Either:
* Remove the association for `gitlab.com` and don't automatically apply a stage/group label, or
* Don't attempt to reapply stage/group labels for `gitlab.com` issues.

cc @meks @rymai @markglenfletcher

Story points: 1.0
Un-scope category labels

### Problem to solve

The label documentation mentions `Subject` labels: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/issue_workflow.md#subject-labels but it currently mixes feature and category labels. We need to clarify this.

For the distinction between **Category** and **Feature**, see https://about.gitlab.com/handbook/product/categories/#hierarchy

There is no official naming/color convention for these labels but an ongoing normalization proposal with https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/169 suggest to leverage scoped labels.

I don't think scoped labels are useful here and they even prevent some existing workflow (e.g. having an [epic related to multiple categories](https://gitlab.com/groups/gitlab-org/-/epics/971)). Requiring to split into sub-epics/issues will generate unnecessary overhead.

NB:  There is a dedicated proposal to normalize feature labels: https://gitlab.com/gitlab-org/quality/triage-ops/issues/247, this issue focuses on feature labels. 

### Example

Issues/Epics are not only about product/category strategies, but there are also engineering initiatives and some of them cover multiples categories depending on how the code is structured. E.g. in ~"devops::secure" we have a lot of overlapping areas between the groups and categories as the code is generic. One unique change to the code can impact several categories.

This MR https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14376 impacts 4 categories.

**Without scoped labels:** 

- we can have 1 epic, 1 issue, 1 MR, all labeled with the 4 category labels. Simple and straightforward.

**With scoped labels:**

- we need 1 parent epic, 4 child epics, 4 issues, all labeled independently with 1 category label.
- the MR can't have the category labels reflecting the change it's providing.
- these are way too much useless items to maintain. Engineers need to update `workflow::xxx` labels and close issues after deployed and tested on prod. This also clutters the issue boards for no benefit.


### Proposal:

- [x] Naming convention `Category: Feature with Spaces And Capital Letters as Desired`
- [x] No scoped labels (mutual exclusion).
- [x] Color `#428BCA`

Once we agree on the convention, tasks list:

- [x] Update the docs by creating a distinct `Category labels` section => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/32053/diffs
- [x] Update any label references in `www-gitlab-com` => https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/28532/diffs
- [x] Update the scripts/automation in this project => https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/274/diffs
- [x] Once the three above MR are merged, update the labels according to the naming convention and color
- [x] Communicate broadly
  - [x] Company call
  - [x] Slack: `#development`, `#quality`, `#product`

Story points: 3.0
Add group and stage label inference to GitLab Charts

The Helm Charts are stored within the GitLab [charts](https://gitlab.com/charts) group and not on gitlab-org. This means label inference is not run on the charts projects.

Applying the labels will enable issue and merge requests reporting by group/stage for the Charts projects. This would cause some chatter on issues & merge requests from GitLab Bot.

Charts are getting moved into gitlab-org eventually: https://gitlab.com/gitlab-org/distribution/team-tasks/issues/422

## Dry Run Results

Pipeline runs (as of 8/5):
- `stage-and-group-labels-hygiene.yml` - 69 matching issues: https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/266437366
- `mr-migrate-legacy-labels.yml` - 15 open merge requests & 294 merged merge requests: https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/266438245

Looking for feedback from @gitlab-org/distribution 

Story points: 2.0
New group::import is now in effect for devops::manage

## Summary

Please list the Stage, Group or Category labels changes required. The change can fall under the 3 scenarios below:

* Adding a new Stage or Group - ~"group::import" under ~"devops::manage" 

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] Triage automation: create or update the stage/group/categories in <https://gitlab.com/gitlab-org/quality/triage-ops/blob/master/lib/devops_labels.rb>. => https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/215
* [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/140
* [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) 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.~~

/cc @gl-quality/eng-prod @jeremy

Story points: 2.0
Remove missed-SLO label from all P3 and P4 Bugs

Identify all P3 and P4 bugs which have a ~"missed-SLO" label and remove it. These are feeding into insights reporting that needs to be removed per https://gitlab.com/gitlab-com/Product/issues/376

@meks @rymai - I tweaked this a bit from our discussion this morning so that it's only looked at GitLab bot applied labels. What do you think?

Story points: 2.0
Proposal: change type labels to be scoped and create children labels per type

## Proposal

1. Change type labels to be scoped, e.g. `type::bug`, `type::backstage`
1. Create children scoped labels per type, e.g. `bug::ui`, `bug::performance`, `backstage::technical debt`, `backstage::static analysis`, `backstage::ci config` etc.

This proposal is extracted from the discussion at https://gitlab.com/gitlab-org/quality/triage-ops/issues/88.

Story points: 3.0
Re-enable the "intelligent" stage/group label inference for open issues

Once https://gitlab.com/gitlab-org/quality/triage-ops/issues/234 is done, all closed and open issues should have a stage/group label set from their team label (except for the ones with multiple team labels), so we should be able to re-enable the "intelligent" stage/group label inference **for open issues**, in the daily schedule.

Story points: 2.0
Add @gitter-badger to the `gitlab-org` group

### Problem

Following the problem described in https://gitlab.com/gitlab-org/quality/triage-ops/issues/174, contributions by @gitter-badger are also marked with the ~"Community contribution" label. See [merge requests](https://gitlab.com/gitlab-org/gitter/webapp/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&author_username=gitter-badger) in `gitlab-org/gitter` group.

### Proposal

Following the relevant slack [discussion](https://gitlab.slack.com/archives/C3W3PSR88/p1564361438009100) (internal), let's move the @gitter-badger as a member (_Developer_) in the `gitlab-org` group. The description of the bot has been updated to include purpose and ownership.

Story points: 1.0
Temporarily remove missed SLO detection for P3

We currently have a high number of ~P3 backlog. 

We need to allow more flexibility and headroom for Product to groom the existing P3 bugs. 

As such, we have decided to temporarily disable the missed SLO detection for ~P3 for the time being and focus on ~P1 and ~P2 

@godfat @rymai @markglenfletcher 

/cc @joshlambert @clefelhocz1 @craig-gomes @tpazitny 

Story points: 2.0
Split "CI & Runner" group

## Summary

Splitting one "CI & Runner" group into two "Continuous Integration" and "Runner" groups.

Please list the Stage or Group labels changes required. The change can fall under the 3 scenarios below:
* Splitting a Stage into multiple Groups
* Changing the Categories in a Stage
* Adding a new Stage

For every case above, the Engineering Productivity needs to ensure that:
* The label change is factored into the triage mechanism.
* Old labels are migrated correctly on affected Issues and Merge Requests.
* Engineering Dashboards in https://quality-dashboard.gitlap.com/groups/gitlab-org is setup correctly as well.

## Action items

* [x] Label migration on existing Issues and Merge Requests: apply the new label to closed/merged and in-progress work. 
* [x] Dashboard creation: create new dashboard view for new stage/group categories https://quality-dashboard.gitlap.com/groups/gitlab-org, location `gitlab_insights.rb`
* [x] If applicable, archive the old labels 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 @godfat @markglenfletcher @rymai @meks

Story points: 3.0
Update the triage operations guidelines to make sure that a heads-up is given in #development/#product/company call when an automation is expected to triage more than 100 issues/MRs at once

Following the recent 1:1 team -> stage/group inference automation (https://gitlab.com/gitlab-org/quality/triage-ops/issues/201), @gitlab-bot added stage and group labels to all the merge MRs under the `gitlab-org` group that had a single team label.

We should give a heads-up in several Slack channels as well as the company call when we anticipate this amount of updates.

We should document that in https://about.gitlab.com/handbook/engineering/quality/guidelines/triage-operations/.

Story points: 2.0
Milestone cleanup report renaming cuts off what was rescheduled

https://gitlab.com/gitlab-org/gitlab-ee/issues/13044


Issue was named as "Automatically rescheduled issues" but was renamed to "Automatically rescheduled to 12.2" the last word was truncated `issues`

![Screen_Shot_2019-07-24_at_8.53.29_PM](/uploads/94e745db82885ab9bd6efe0c7de9a434/Screen_Shot_2019-07-24_at_8.53.29_PM.png)

Story points: 1.0
Change the "intelligent" stage/group label inference logic to do the team -> stage/group inference first, and add a new "team to stage/group" inference logic

Change the "intelligent" stage/group label inference logic to:

1. Only use the 1:1 team -> stage/group inference for issues for now
1. Remove the 300 threshold for issues so that all open issues gets a stage/group from their single team label
1. Finish 1:1 team -> stage/group inference for issues 
1. (Optional depending on the anticipated number of issues that would be updated) Re-add a threshold for issues
1. Use the "intelligent" inference for issues

Story points: 3.0
Close the merge request milestone movement report sooner

The report looks like: https://gitlab.com/gitlab-org/gitaly/issues/1784

We want to close it automatically, but because of the ordering we're processing the rules, this will only get closed in the next run.

We should do better, but for now we can just wait for tomorrow.

>>>
The report was an issue, not a merge request, so this of course won't do anything. It doesn't close the issue right now because the report was only generated after we processed the merge requests. Whenever we're trying to close the report, the report for merge requests wasn't generated yet!

So we need to run the same issue rule again after merge request rule is done. Well, or wait for tomorrow...
>>>

----

The following discussion from !178 should be addressed:

- [ ] @godfat started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/178#note_189649103):  (+2 comments)

    > Close for merge request report, too: https://gitlab.com/gitlab-org/gitlab-ce/issues/64291

Story points: 2.0
Make it possible to configure policies/unlabelled-issues.yml

Currently `policies/unlabelled-issues.yml` is a triaging package which has fixed names and people to rotate, so we can't reuse it for other groups. However we want to make it configurable so that we can easily apply to other groups.

The current rotation code is:

``` ruby
potential_triagers = %w[@markglenfletcher @godfat @ddavison @mlapierre @at.ramya @sliaquat @tnikic @zeffmorgan @tpazitny @wlsf82 @dchevalier2 @asoborov @grantyoung @jennielouie].shuffle
list_items = resource[:items].split("\n")
items_per_triagers = potential_triagers
  .zip(list_items.each_slice((list_items.size.to_f / potential_triagers.size).ceil))
  .to_h.compact

items_per_triagers.each_with_object([]) do |(triager, items), text|
  text << "#{triager}\n\n#{items.join("\n")}"
end.join("\n\n")
```

And:

```
/assign #{items_per_triagers.keys.join(' ')}
/label ~Quality ~"triage\-package"
```

We can aim to make it look like this:

``` ruby
items_per_triagers = pick_triagers(resource[:items], ENV['TRIAGERS'])
```

And use it like:

``` ruby
#{ items_for_triagers(items_per_triagers) }

/assign #{items_per_triagers.keys.join(' ')}
/label ~"#{ENV['TRIAGERS_GROUP']}" ~"triage\-package"
```

The following discussion from !183 should be addressed:

- [ ] @markglenfletcher started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/183#note_191755695):  (+1 comment)

    > Approach looks good to me. I agree with letting these parts of the flow be disabled for now.
    > 
    > I think that we should strive to enable the unlabelled/untriaged triage package jobs for all projects in the future, but instead of looping in the Quality team, allow a list of triage team members to be defined that are best suited to that project. I feel that this will allow teams to keep track of reported issues and increase responsiveness when communicating with issue authors.

Story points: 3.0
Extend daily/weekly schedules to other projects

Try to find the right balance for repeating and flexibility

* [x] Gitaly: https://gitlab.com/gitlab-org/quality/triage-ops/issues/184
* [x] Runner: https://gitlab.com/gitlab-org/quality/triage-ops/issues/68 and https://gitlab.com/gitlab-org/quality/triage-ops/issues/164
* [x] QA

Story points: 2.0