giseldo/neodataset huggingface dataset:
Create a new set of scoped labels for product Sections

## Summary

I'd like to see scoped labels for GitLab Sections (Dev, Ops, Secure, Enablement), as part of our [product hierarchy](https://about.gitlab.com/handbook/product/categories/#hierarchy). This scoped label would be applied automatically whenever a group:: label is present that aligns to a group within that section in our product hierarchy.

## Why

My motivation is that it would help me personally search across all issues with a certain additional label (for instance all P1 bugs, Customer, or CEO Interest) across the entire section. In that regard it has a limited set of potential users, namely myself and other section leaders.


## Plan

- [X] Create labels for section
  * ~"section::dev" 
  * ~"section::enablement" 
  * ~"section::growth" 
  * ~"section::ops" 
  * ~"section::securedefend" 
- [x] Notify in #development, #product prior to the first run of the inference so that subscribers can turn off. [Slack](https://gitlab.slack.com/archives/CU4RJDQTY/p1596722811156600)
- [ ] Add section inference to auto-label inference that applies without a comment from GitLab bot
  * Infer and apply section label from group label
  * Update documentation at https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-labelling-of-issues => https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/57538
  * Communicate via Slack and What's Happening at GitLab

Story points: 3.0
Group::Spaces changes

## Summary

~"group::spaces" is being absorbed into ~"group::access" with https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/48457. We need to ensure that the triage reports and labels are updated with the change. 

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>.
* [x] https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/500 (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
  * [x] 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] (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.
* [x] https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/499 (If applicable) Update the group triage report definition to use the new label
* [-] (If applicable) Update the group label's description to refer to the new Stage.

/cc @gl-quality/eng-prod

Story points: 2.0
Category::Billing does not exist

## Problem

The `gitlab-org:stage-and-group-labels-hygeine` job failed and retried the job 2 additional times in https://gitlab.com/gitlab-org/quality/triage-ops/pipelines/138494857. https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/43007 was merged earlier today which introduced a new Billing Category but did not have a label. 

This caused the Label Inference comment to be applied 3 times since the label didn't exist like:
![image](/uploads/3a46502c8a37c7f2aee269ccbcd96117/image.png)

Story points: 1.0
Investigate why are we triggering a lot of unuseful pipelines

The only thing those pipelines were doing was `lint-policies`, and apparently we don't need them? /cc @gl-quality/eng-prod 

![Screen_Shot_2020-04-10_at_17.33.41](/uploads/770eec5a7b715d1328fc39aa6d691068/Screen_Shot_2020-04-10_at_17.33.41.png)

Story points: 1.0
Update Relevant Labels and Automation to remove the word `Grooming`

[This MR](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/45894) added Grooming to our mis-used terms. 

There was one follow-up action from that MR:

> Adjust labels with the word Grooming in them in [GitLab.org](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=grooming) and [GitLab.com](https://gitlab.com/groups/gitlab-com/-/labels?utf8=%E2%9C%93&subscribed=&search=grooming) projects 

Can we adjust the labels as appropriate and update any automation which references them?

Story points: 1.0
Idle merge request triage report

## Problem

Merge requests are being idle with no activity on them and are merged more than 30 days from the time when they are opened. [March release analysis](https://docs.google.com/document/d/1o9cJACy8ACxUS2WpvdFdikuIR_Db6Bxdbzja-e9aBGc/edit#) showed that 4% of all MRs in March took more than 30 days to merge (122). We want to better understand this population and determine if automation can help reduce number.

## Plan

Create a stale merge request group triage package which collects group MRs that have been `updated_at` `older_than` `4 weeks` and run every two weeks. The triage package will be assigned to the group Engineering Managers.

- Assigned to: Group Engineering managers
- Report frequency: On 8th and 23rd every month

### Template 

>>>
Hi #{assignee}!

This is a group level idle merge request report. This report contains open Merge Requests that have not been updated in four weeks for review. 

> Please review these merge requests to identify if there are any steps that can shorten the time to merge, such as reminding the author about it, changing the DRI, etc.
---

## Stale merge requests

1. [gitlab-org/gitlab!123](link-to-mr) - MR Title
1. [gitlab-org/gitlab!234](link-to-mr) - MR Title

>>>

## References

- https://docs.google.com/document/d/1o9cJACy8ACxUS2WpvdFdikuIR_Db6Bxdbzja-e9aBGc/edit#
- https://docs.google.com/spreadsheets/d/1hTPsJ1ueYfzjgqc3vDsRa5iGOEtbTsNrVfYJNh5oifM/edit#gid=24949791
- Handbook update: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/48764

Story points: 5.0
Remove testcases default labeling

## Problem

The ~"group::not_owned" default label that is applied to issues in https://gitlab.com/gitlab-org/quality/testcases/-/issues will be creating confusion with ~"group::not_owned" being looked at for a potential Product triage package: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/6245

Originally this policy was added with https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/345

## Proposal

- [ ] Turn off policy for ~"group::not_owned" on the testcases project 
- [ ] Unlabel issues with ~"group::not_owned" within testcases project & label with ~Quality.

Story points: 2.0
Triage automation for devops::verify to report missing category fails to detect Category:MergeTrains is applied

The triage automation/report for ~"devops::verify" to report missing category fails to detect when an issue already has the ~"Category:Merge Trains" label applied.

The ~"Category:Merge Trains" was recently moved from Release stage to Verify stage in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/41969.

Story points: 1.0
Rename `triage-package` to `triage-report`

## Summary

This template is for the following types of label changes

* Adding a new Stage or Group
* Renaming an existing Stage or Group

For every case above, the Engineering Productivity team needs to ensure that:

* The label change is factored into the triage mechanism.
* Old labels are migrated correctly on affected issues and merge requests.

### Action items

* [ ] (If applicable) Rename ~"triage-package" to ~"triage-report"
* [ ] (If applicable) Update the triage mechanism to use the new label


/cc @gl-quality/eng-prod

Story points: 2.0
Global Search group and category name change

As part of https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/42162 the `Search` group and category were changed to `Global Search`.

We also used the feature label `elasticsearch` heavily which I'd like to rename to:

`Advanced Global Search`

If we could also introduce one for `Basic Global Search` that would be ideal as well.


Please let me know if additional details are needed.

## Summary

This template is for the following types of label changes

* Adding a new Stage or Group
* Renaming an existing Stage or Group

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::search" to ~"group::global search" 
* [x] Rename ~"Category:Search" to ~"Category:Global Search" 
* [x] Rename ~elasticsearch to ~"advanced global search" 
* [x] Update the group triage package definition to use the new label: https://gitlab.com/gitlab-org/gitlab-insights/-/merge_requests/190
* [-] (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.

/cc @gl-quality/eng-prod

Story points: 2.0
Add Triage Policy for Support Forum Auto-Close

## Proposal

As apart of https://gitlab.com/gitlab-com/support/support-team-meta/issues/1346#plan, create a new daily policy to lock and close issues in https://gitlab.com/gitlab-com/support-forum/ that have not had a comment in last 30 days. 

This policy would be similar to https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/projects/gitlab-foss/move-gitlab-foss-issues-to-gitlab.yml. 

```
conditions:
  state: opened
```

Post a message within https://gitlab.com/gitlab-com/support/support-team-meta/issues/1346#plan

>>>
Hey! :wave:

We're closing the Support Forum issue tracker in favor of the [community forum](https://forum.gitlab.com) and [support channels](https://about.gitlab.com/support/#contact-support). We recognize that the Support Forum issue tracker has not received much attention in the last few months, and want to redirect our community members to locations that are regularly monitored by GitLab staff.

As a result, we are closing all issues.

If the issue you're facing is a *reproducible* bug, please search for an existing issue on the [GitLab project tracker](https://gitlab.com/gitlab-org/gitlab/issues) or [file a bug issue](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Bug).

If you are still encountering an issue, please raise a new one in the [appropriate place](https://gitlab.com/gitlab-com/support-forum/-/blob/master/README.md) and link back to the closed issue if there's any important context that should be preserved.

The current project will become a read-only project with an [updated Readme](https://gitlab.com/gitlab-com/support-forum/-/blob/master/README.md) on where to raise new issues.
>>>
  

## Open Questions

- [x] Is `updated_at` for the issue sufficient? This is [available through `gitlab-triage`](https://gitlab.com/gitlab-org/gitlab-triage#date-condition) and would make the policy simpler. 
- [x] Are support forum issues being moved to gitlab-org/gitlab or closed? Based on https://gitlab.com/gitlab-com/support/support-team-meta/issues/1346#note_283532621 it seems move but I'm not sure that's the right action for every support-forum issue.

Story points: 1.0
Issues without category report includes issues with category

https://gitlab.com/gitlab-org/gitlab/issues/208610 has issues listed that include Category labels for ~"devops::release" 

For example: 

- https://gitlab.com/gitlab-org/gitlab/issues/207978 includes ~"Category:Auto DevOps" and ~"Category:Kubernetes Management" 
- https://gitlab.com/gitlab-org/gitlab/issues/207852 includes ~"Category:Release Governance" 
- https://gitlab.com/gitlab-org/gitlab/issues/34264 includes ~"Category:Audit Events" and ~"Category:Release Governance"

Story points: 1.0
Apply ~"Community Contribution" for merged_mrs

## Objective

Minimize the amount of manual ~"Community contribution" application for merged community MRs like: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23301#note_292568353

## Proposal 

- [ ] Apply ~"Community contribution" for **open and merged** Merge Requests from `non-gitlab-org` members that are not already labelled ~"Community contribution".

Story points: 2.0
Deliverable labels removed from 12.8

Yesterday, the Deliverable labels were removed from open 12.8 Deliverables. It looks like it may have been done by the jobs in https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/366

https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4838 is an example where it removed the Deliverable label, without updating the milestone or setting the missed label? That the time this issue was a Deliverable assigned to 12.8 . In distribution we encountered this on a handful of issues that we were expecting to be moved to 12.9


cc\ @ljlane @mendeni

Story points: 1.0
Execution order for Label Inference and Triage Report

## Problem

The order of Category Label Inference and Triage report is causing some confusion and I'm not able to easily track down what ran when with the large amount of pipelines. . 

From @jyavorska on [Slack](https://gitlab.slack.com/archives/C3JJET4Q6/p1581932656014900): 

>>> 
Hello, possibly it's still expected but I noticed the bots ran out of order again - I received triage reports of the need to apply category labels that another bot came along and automatically applied category labels to. (edited) 
>>>

- [ ] What is the order for the pipelines on 2020-02-16 on `gitlab-org`
  - Label Inference daily: https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/439127366
  - Team Triage weekly: https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/439125366
- [ ] Is there a way to simplify this or ensure that triage packages are created after the label inference for that week.

Story points: 2.0
Apply ~bug to ~availability issues

## Proposal 

- [ ] Add a hygiene rule for the gitlab-org group level which will apply ~bug for all issues labeled ~availability without ~bug. 

* See @meks reasoning here:

> As I stated before in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/39270#note_280407345, ~availability issues are a category of bugs, we don't have a good hygiene on label yet (which we will fix with automation). This iteration aims to have better clarity and specifics on how to deal with bugs/defects that immediately impacts GitLab.com ~availability. The overall ~bug pie is huge, this sets out to make a subset of that better with clearer and specific actionable steps.

Story points: 2.0
Use Issue and Merge Request resource class to determine how to infer the labels

Previously the method `#new_stage_and_group_labels_from_intelligent_inference` uses `infer_from_category: false` for merge request label inferrence.

With https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/390#note_281173182, the inference between an Issue and Merge Request are becoming orthogonal.

I'm suggesting to change from using `infer_from_category` flag to determine whether to infer for an MR or an issue to using the resource class itself.

Story points: 1.0
Add comment mentioning that the author's correct group could not be determined

Following from https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/390#note_278719721, some MRs may not have group label applied because the author's correct group could not be determined.

This may happen in the following scenarios:
- MR author is a gitlab team member:
  - The MR author's group is not listed in `www-gitlab-com` `data/team.yml` under `departments`
  - The MR author may belong to more than one teams (e.g member of one team and intern in another)
- MR author is a community member

/cc @gl-quality/eng-prod

Story points: 3.0
Cut down on assignees on group triage report issues

### Summary

Sometimes group triage report issues are created but do not need to cover a certain topic.

For example, all frontend bugs are scheduled so there is no section for frontend bugs. In this case we still assign the Frontend Engineering Manager to the triage report. Let's make it so that people that do not need to be involved in a triage report are not assigned

### Aims

- Cut down on the number of triage reports that people are unnecessarily assigned to
  - Hopefully this will make triage reports less annoying and improve engagement

### Proposal

Instead of using a collection of assignees, use a Hash by department type and add a quick action to assign the relevant users as part of their summary action

Story points: 3.0
Group or stage report for flaky-master specs

There's a concern that quarantined flaky-master specs could stick around. Should we create a report around flaky-master specs that have passed a certain threshold?

## Proposal

- Add a section to the team-triage report that lists ~P1 ~"failure::flaky-test" non-~QA issues - ~QA issues are triaged by the Quality Triage Report

Story points: 1.0
`dry-run:schedule` for now will only run the first schedule from the variants

I realized this when I was thinking how to dry-run some of the schedules. The problematic code is in `Schedule::Manager#find_schedule!`:

``` ruby
def find_schedule!(project_path)
  schedules_specification.find do |spec|
    spec.project_path == project_path
  end ||
    raise(
      InvalidDryRunScheduleName,
      "Cannot find schedule named #{project_path.inspect} in #{raw_schedules_path}")
end
```

It's using `find` to find the first matching specification, however, there can have multiple ones with the same `project_path`. `find` is a linear search, so we always return the first one.

For example, in the current schedule `gitlab-org/gitaly`, there are two schedules underneath:

``` yaml
gitlab-org/gitaly:
  base:
    variables:
      TRIAGE_SOURCE_TYPE: projects
      TRIAGE_SOURCE_PATH: 2009901
  variants:
    - id: 29054 # https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/29054/edit
      active: true
      description: '[DAILY] gitlab-org/gitaly'
      variables:
        # hygiene
        TRIAGE_LABEL_ACCEPTING_MERGE_REQUESTS: 1
        TRIAGE_LABEL_MISSED_SLO: 1
        TRIAGE_LABEL_REMINDERS: 1
        TRIAGE_MOVE_MILESTONE_FORWARD: 1
    - id: 29055 # https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/29055/edit
      active: true
      description: '[WEEKLY] gitlab-org/gitaly'
      cron: '0 0 * * 1'
      variables:
        # package
        TRIAGE_COMMUNITY_MERGE_REQUESTS: 1
        TRIAGE_MISSING_CATEGORIES: 1
        TRIAGE_TEAM_TRIAGE_PACKAGE: 1
```

For now it'll only dry-run the first one (daily), ignoring the second one (weekly)

This might not be important to fix before we actually need it, but we need to know this limitation.

/cc @gl-quality/eng-prod

Story points: 1.0
Apply default labels for gitlab-org/charts/gitlab-runner

## Proposal

Apply runner related labels to Issues in https://gitlab.com/gitlab-org/charts/gitlab-runner similar to https://gitlab.com/gitlab-org/quality/triage-ops/blob/master/policies/projects/gitlab-runner/default-labels.yml

    - ~"devops::verify" 
    - ~"group::runner"
    - ~"Category:Runner"

Story points: 2.0
Update auto-labeling from the bot to account for new categories

* Groups are now called Subgroups https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/36874
* Category updates for Manage:Compliance - Audit Events, Audit Management, and Compliance Controls https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/34261
* Static site editor to Create https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/32938
* Update Secure Stage with new Group and Categories https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/35204
* Update Defend Stage with new group "Anomaly Detection" and moving categories to correct group https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/35196

cc @gl-quality/eng-prod

Story points: 1.0
Feedback on Unlabelled Issues Triage Package

## Summary

During the [EP Team meeting](https://docs.google.com/document/d/1QxRQRLP-GpiCis4oFvm0NLm1lJm6WcTP2rcYfn6RC-Y/edit#bookmark=id.1ntpraugze7) we discussed the reduced participation in the [Unlabelled issues triage package](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#newly-created-unlabelled-issues-requiring-first-triage) and would like feedback on how it can be improved. 

### Improvements

- Utilize OOO status indicator for triage package - https://gitlab.com/gitlab-org/quality/triage-ops/issues/162
- Investigate making PM DRI for check for duplicate issues - https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/505
- Reduce load with https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/295

Story points: 1.0
Apply ~documentation to Open ~"Community contribution" documentation MRs

### Proposal 

Apply ~documentation to open  ~"Community contribution" MRs that have changes to `docs/`. 

As @godfat suggested, this might be easier than trying to react with Triage-Serverless. 

From https://gitlab.com/gitlab-org/technical-writing/issues/39#note_240604168 to help facilitate ~"Community contribution" doc improvements.

Story points: 3.0
Label missed-deliverable and missed milestones after the milestone expires but before the 22nd

This is due to the confusion of the EMs, our self-managed customers, the wider community and also a request from the delivery team.

We have 2 dates to juggle for a given release.
1. On the 17th when the milestone expires. 
1. When we release on the 22nd.

Currently, there is still a possibility of things being part of the release even if the issue is closed after the 17th but before the 22nd. This is due to the time window between these 2 dates. There is confusion due to bot labeling. Some ~"missed-deliverable" are still being delivered since labeling on the 17th was too soon. After discussing with @marin the general idea is to leave the milestone as they are and tack on the additional buffer with the bot labelling.


Until we can actually infer via automation, how every change makes it through to production, we have the below as an iteration.

### Proposal 

Label ~"missed-deliverable" and `missed:x.y` version on the last business day before the 22nd.
* If the 22nd falls on a friday, we label this on thursday the 21th.
* If the 22nd falls on a monday, we label this on friday the 19th.
* If the 22nd falls on either weekend days, we label this on friday the 21th or the 20th.

This labeling will happen on the last business day at midnight pacific time. 

#### Implementation

For the logic, we are already pulling from the milestone dates. I am proposing that this should be an addon so we still rely on what is in `gitlab-org` milestones but calculate it in respect to the 22nd. 

* From a given milestone, find the last day (expire date) that will give us the month/year.
* From the month/year look up what day is the 21st of that month/year. 
  * If the 21st is a weekday, bot runs labelling on that day.
  * If the 21st is sunday, bot runs labelling on the 19th.
  * If the 21st is saturday, bot runs labelling on the 20th.


Thoughts @godfat @gl-quality/eng-prod ?

cc @marin @gitlab-org/delivery

Story points: 3.0