giseldo/neodataset huggingface dataset:
Automation to ensure that issues and MRs with legacy team labels have a 1:1 mapping to their devops stage or group label

We need an on-going automated rule to apply `devops::xxxx` to issues and MRs based on their legacy team labels. 

This is the first step to ensure we can transition each groups to use the new labels.

We would want a rule that continuously runs and auto adds the new stage and group labels where these old team labels exist.  

**Stages** 

* ~Manage  => ~"devops::manage" 
* ~Create => ~"devops::create" 
* ~Plan => ~"devops::plan"
* ~Verify => ~"devops::verify" 
* ~Package => ~"devops::package" 
* ~Release => ~"devops::release" 
* ~Configure => ~"devops::configure" 
* ~Monitor => ~"devops::monitor" 
* ~Secure => ~"devops::secure" 
* ~Defend => ~"devops::defend" 
* ~Growth => ~"devops::growth"
* ~Enablement => ~"devops::enablement"

**Groups**

* ~Gitaly =>  ~"group::gitaly"  
* ~Gitter =>  ~"group::gitter"
* ~Health => ~"group::health" 
* ~Distribution =>  ~"group::distribution" 
* ~Geo =>  ~"group::geo" 
* ~Memory =>  ~"group::memory" 
* ~Ecosystem =>  ~"group::ecosystem" 

#### Phases

##### Merge Requests
1. Add devops stage labels and (where necessary) group labels to merged Merge Requests that have a clear 1:1 mapping between legacy and stage label !184
   - This accounts for the majority of throughputs and will make them visible in the stages dashboards
     - https://quality-dashboard.gitlap.com/groups/gitlab-org/stages/devops::create
     - https://quality-dashboard.gitlap.com/groups/gitlab-org/teams/create
2. Determine devops stage label to apply to merged Merge Requests that do not have a clear 1:1 mapping
   - Some MRs have several legacy labels and it's unclear which stage label should be applied
   - We cannot apply two as stage labels are scoped labels
   - We can use feature label inference to determine stage labels where possible and manual labelling for the outstanding MRs
3. Determine devops stage label to apply to merged MRs with no legacy label
   - We can infer the stage labels from the category labels where possible
3. Add devops stage labels to open MRs in the same manner as 1, 2, and 3
   - Not essential as only `merged` MRs are counted for throughputs
4. Determine group labels for merged MRs through author


##### Issues
1. Add devops stage labels to issues via feature label inference implemented in https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/155
   - We are in the process of rolling this out completely here for both issues and MRs resources  
      - https://gitlab.com/gitlab-org/quality/triage-ops/issues/211

Story points: 4.0
Consider removing the ~group label in favor of the ~groups label

It seems the ~group label (https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=✓&state=opened&label_name[]=group) is duplicating the ~groups label (https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=✓&state=opened&label_name[]=groups).

I suggest removing the ~group label in favor of the ~groups label.

Plan of action:

- [x] Bulk-add the ~groups label to all the issues/MRs that currently have the ~group label set
   - [x] Issues: https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=group
   - [x] MRs: https://gitlab.com/groups/gitlab-org/-/merge_requests?label_name%5B%5D=group
   - [x] Epics: https://gitlab.com/groups/gitlab-org/-/epics?label_name%5B%5D=group
- [x] Remove the ~group label

@jeremy What do you think since you're the product manager for ~"group::access"?

Story points: 1.0
Move all issue rescheduling to happen on the 23rd instead and move it to the next milestone

Captures the following work on rescheduling for https://gitlab.com/gitlab-com/www-gitlab-com/issues/4593

* [x] Feature freeze and missed deliverables https://gitlab.com/gitlab-com/www-gitlab-com/issues/4593#missed-deliverable
  * Remove feature freeze detection on the 7th
  * Move missed deliverable when milestone is closed.
  * Keep bot message
* [x] Generic missed items https://gitlab.com/gitlab-com/www-gitlab-com/issues/4593#generic-missed-items-clean-up
  * Move missed issues and MRs when milestone is closed.
  * ~~Remove report generation since we are already labeling it with `missed:x.y`~~
  * Close the report after generation
  * Change the report to use numbered list
  * Fix the bug updating the title for the report
  * Remove bot message on  `missed:x.y` just move the issue

Story points: 2.0
Remove `Deliverable` label if milestone is beyond current+1

The ~Deliverable  label is intended to be applied to issues once they have been formally included in a release, gone through kickoff, etc: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#release-scoping-labels

There are issues however where the ~Deliverable   is applied to pretty far out issues, for example right now there are 13 ~Deliverable   for %"12.4", which has not had any planning rigor. This is proving to frustrate our user community, as this label is now misleading. What has generally happened is the issue was pushed out of a release, and people forgot to remove the label.

It would be great if we could remove this automatically, to improve our issue hygiene.

Story points: 3.0
Move generic code to gitlab-triage and keep only domain specific code here

The following discussion from !149 should be addressed:

- [ ] @rymai started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/149#note_182469799):  (+2 comments)

    > 1. `lib/extension.rb` sounds like a very generic name
    > 1. Why not implementing the generic part of this feature into `gitlab-triage` directly (i.e. `EngineExtension`, `RulePolicyExtension`, `IssueBuilderExtension#initialize`)? That way we'd only override `IssueBuilderExtension#description` to add the heatmap.

* [ ] Rename `lib/extension.rb` -> https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/155
* [ ] Introduce another object to contain the conditions and the raw resources -> https://gitlab.com/gitlab-org/gitlab-triage/issues/147
* [ ] Expose the raw resources so we can extend it

The most offending code is:

``` ruby
yield(resources, conditions.merge(all_resources: all_resources))
```

@rymai had a comment about it: https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/149#note_182469796

> Could we change this method in `gitlab-triage` to directly yield `resources, conditions, resources_without_limit` instead? I find it hackish to merge `all_resources: all_resources` into `conditions` here... :thinking:

To be honest, I spent a lot of time figuring this out, and I got really confused around this code. This was because the object we put into `BasePolicy#resources` can actually have different types for `SummaryPolicy` and `RulePolicy`.

I left a comment in `lib/gitlab/triage/policies/summary_policy.rb`

``` ruby
# Due to resources is a different type, this will never work
# FIXME: We should try to make sure type is consistent for resources
def comment?
  false
end
```

This shares the same issue. Depending on the instance, `resources` can mean different things. In `RulePolicy` it's an array of resources, but in `SummaryPolicy` it's a hash mapping from rules to the resources.

In order to fix the confusion here, I would like to introduce a new class wrapping it. I don't know how to name it yet, but it should carry the difference.

And then, we can attach this `all_resources` (or raw resources) to this object, instead of attaching it to the conditions.

I need to attach it to the conditions for now, because I don't know how to properly attach it to either an array or a hash (!) If we try to detect that, it's going to be even more confusing...

I consider that a ~"technical debt" without adding an actual object for that part, and I think we need to fix it now before we move on, because we do need to add something on top of it now.

Story points: 1.0
Put issues filter link to the heat map

The following discussion from !149 should be addressed:

- [ ] @godfat started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/149#note_182700145): 

    > We can definitely construct the issue link here, but I find it not so straightforward because we need to put up the query by ourselves, and this is pretty isolated so I think we can probably do this later.

Story points: 2.0
Don't label group/project access token mrs as "community contribution"s

See https://gitlab.com/gitlab-org/secure/vulnerability-research/advisories/cves-private/-/merge_requests/1467 for example

I guess we should not be labelling these as community contributions- that way they won't come up in the daily community mr triage report for example

/cc @gl-quality/eng-prod

Story points: 1.0
Are we really stubbing everything in devops_labels_spec.rb?

The following discussion from !1949 should be addressed:

>>>
I have a question though. I thought all of the api calls are stubbed in the spec [here](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/spec/lib/devops_labels_spec.rb#L17), how are we still getting a failing pipeline? I really thought that stubbing would have prevented this type of surprise broken pipelines
>>>

Story points: 2.0
JiHu AppSec Notifier wasn't triggered on a JiHu Contribution

The [JiHu AppSec notifier](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/jihu-security-review-process.html) was not triggered on https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90956#note_a8f30383f81d5e765f9e0132e3f5d6d4d32bcd80 and we need to find out why.

Story points: 2.0
Remind MR authors that set MWPS that this is not a compliant action

## Objective

Reduce the amount of MRs merged to `gitlab-org/gitlab` by the MR author as apart of https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/sec-compliance/observation-management/-/issues/318

## Proposal

Remind the MR Author (similar to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89719#note_994821846) when they set MWPS on their MR that this is a non-compliant action and another maintainer should merge the MR. 

Use https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/triage/processor/remind_merged_mr_deviating_from_guidelines.rb as a reference implementation on the merge when pipeline succeeds event. 

### Limitations

- Approvals can't be revoked (https://gitlab.com/gitlab-org/gitlab/-/issues/367392) so we are going to inform first and then block merging with https://gitlab.com/gitlab-org/gitlab/-/issues/366696

Story points: 3.0
Don't ask community contributions to set a type label for now

It seems we're missing the logic to exclude ~"Community contribution" in https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/d7baaeed5b5b32ad8e8046cb196ec0e5838ee605/triage/job/type_label_nudger_job.rb#L17.

See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88409#note_958051092 for an example.

Story points: 1.0
Suggest community contributors to use gitlab-org/gitlab on creating an MR on gitlab-org/gitlab-foss

`@gitlab-bot` should suggest community contributors to use gitlab-org/gitlab on creating an MR on `gitlab-org/gitlab-foss`.

Currently bot suggests the same message with one for `gitlab-org/gitlab`.

### Example
https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/33104#note_954012005

Story points: 1.0
Consider making the `request_review` reactive command response message more concise

The response message for the `request_review` reactive command is currently a bit verbose I think.

Example of the current behavior (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87857#note_951003725):

![Screen_Shot_2022-05-19_at_12.32.26](/uploads/1cabd153137106ed32caa8e7998a82fa/Screen_Shot_2022-05-19_at_12.32.26.png)

Making it more concise would reduce the noise for ~"Community contribution" authors (and everyone else).

Story points: 1.0
Auto apply Hackathon label and link with tracking issue for FY23Q2 Hackathon

## 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-com, https://gitlab.com/gitlab-org

* Automation that does not require an assignee.
  * Labelling ~"Hackathon" on any ~"Community contribution" labeled MR during May 9th, 12 pm UTC (noon), and May
  13th 12 pm UTC (noon)
  * Leaving the following comment: 

` This MR will be considered [part of](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/65) the quarterly [GitLab Hackathon](https://about.gitlab.com/community/hackathon/) for a chance to win a [prize](https://about.gitlab.com/community/hackathon/#prize).

Can you make sure this MR is mentioning/linking the relevant it's attempting to close?

Thank you for your contribution!`

cc @kwiebers

Story points: 1.0
Implement type label nudger processor

## Objective

Reduce maintenance for updates to type label nudge and allow for easier rollout to projects

### Why is this important? 

The 3 types (Bug, Feature & Maintenance) is key to our report to industry analysts. It is important for GitLab to communicate effort spent into a format that is easily understandable widely in the industry. We provide this metric to our leadership reporting and improve the accuracy with subtypes categorization. 

Additionally tracking accurate work output allows the team to compare output to backlog and adjust focus accordingly. 

### Proposal

1. Create a type label discussion for non-\~"Community contribution" MRs opened without a type for the [top 20 offending undefined projects](https://app.periscopedata.com/app/gitlab/1021219/Type-Research?widget=14627996&udv=0) with the below message requesting the MR be classified label. => https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/1374
1. Expand to additional projects based on [undefined ratio](https://app.periscopedata.com/app/gitlab/1021219/Type-Research?widget=14627996&udv=0) (what proportion of merged MRs do not have a type) for projects over 20 MRs in the last 90 days
1. Expand to all `is_part_of_product` projects

```
:wave: @#{event.event_actor_username} - please add ~"type::bug", ~"type::feature", ~"type::maintenance", or a [subtype](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification) label to this merge request. 

        - ~"type::bug": Defects in shipped code and fixes for those defects. This includes all the bug types (availability, performance, security vulnerability, mobile, etc.) 
        - ~"type::feature": Effort to deliver new features, feature changes & improvements. This includes all changes as part of new product requirements like application limits.
        - ~"type::maintenance"`: Up-keeping efforts & catch-up corrective improvements that are not Features nor Bugs. This includes restructuring for long-term maintainability, stability, reducing technical debt, improving the contributor experience, or upgrading dependencies.

        See [the handbook](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification) for more guidance on classifying. 
```

Story points: 2.0
Replace SUS with non-sus label when feature::addition or Actionable Insight::exploration needed is applied to issues

## Objective

Replace ~SUS with ~"non-SUS" if ~"feature::addition" or ~"Actionable Insight::Exploration needed" is on an issue so that the rules in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/100632#note_918555284 can be automated.

## Acceptance Criteria

* Convert ~SUS labels to be scoped: https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/982#note_923537080

Story points: 1.0
Gitlab::Error::BadRequest: Server responded with code 400, message: 400 Bad request - Note {:note=>["can't be blank"]}. Requ...

Sentry Issue: [TRIAGE-OPS-DA](https://sentry.gitlab.net/gitlab/triage-ops/issues/3270725/?referrer=gitlab_integration)

```
Gitlab::Error::BadRequest: Server responded with code 400, message: 400 Bad request - Note {:note=>["can't be blank"]}. Request URI: https://gitlab.com/api/v4/projects/20699/merge_requests/6055/notes
  gitlab/request.rb:71:in `validate'
    raise error_klass, response if error_klass
  gitlab/request.rb:55:in `block (2 levels) in <class:Request>'
    validate response
  triage/triage/reaction.rb:40:in `post_request'
    Triage.api_client.post(path, body: { body: body }) unless Triage.dry_run?
  triage/triage/reaction.rb:12:in `add_comment'
    Reaction.post_request(path, body)
  triage/processor/reactive_labeler.rb:50:in `post_label_command'
    add_comment <<~MARKDOWN.chomp
...
(16 additional frame(s) were not displayed)
```

I believe the issue happens when someone asks to apply a label that doesn't match the allowed pattern, e.g. `@gitlab-bot label \~"group::Omnibus Package"`.

Story points: 2.0
Bot message cleanup refactoring

We have a wide implementation of bot automated message and this can be overwhelming and noisy to our team members. 


Create this issue to start reducing / redundant or irrelevant messages 

1. Bot messages containing code related requirements in documentation MR 
    - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80756#note_920336781 
    - Add docs minimal job context?
1. Redundant prompt to apply labels 
    -  https://gitlab.com/gitlab-org/gitlab/-/issues/359166#note_914475256

cc @rymai @kwiebers I created this issue to start refactoring bot messages based on feedback heard. 

If you have seen anymore of these please add to them

Story points: 2.0
Consider enabling the `LabelInference` processor for `gitlab-com/runbooks`

We should consider enabling the `LabelInference` processor for the https://gitlab.com/gitlab-com/runbooks project, e.g. https://gitlab.com/gitlab-com/runbooks/-/merge_requests/4518#note_bb9e07f01265e875fefcd649863efe112f391cb8.

Related to https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/1190#note_846835116.

Story points: 2.0
Remove conflicting sub-work type if a different scoped type is applied

## Objective

Reduce misalignment of sub and parent [Work types](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification) on issues and merge requests.

A one-off migration may need to be done to fix any contradicting parent and sub type on open issues and merge requests.

This would be similar to https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/triage/processor/label_inference.rb but to remove child labels when a different type label is added (currently it adds and removes parent labels when a child label is added).

Story points: 3.0
Add New  Category Labels for Group:: Authentication and Authorization

## Summary

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/101822
* [ ] (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
Move Category:Pages issues to group:editor

## Summary

This template is for new or renaming Category labels. This review helps to ensure there will be no impact with triage automation and reports.

~"group::editor" is now the group responsible for ~"Category:Pages" so we need to migrate the issue and MR labels accordingly. This should only be done on **open** issues and MRs.

More detail here: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/100227#note_895335961



### Action items

* [ ] 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
* [ ] (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
Gitlab::Error::BadRequest: Server responded with code 400, message: 400 Bad request - Note {:note=>["can't be blank"]} in `AvailabilityPriority`

Sentry Issue: [TRIAGE-OPS-BM](https://sentry.gitlab.net/gitlab/triage-ops/issues/3237312/?referrer=gitlab_integration)

```
Gitlab::Error::BadRequest: Server responded with code 400, message: 400 Bad request - Note {:note=>["can't be blank"]}. Request URI: https://gitlab.com/api/v4/projects/278964/merge_requests/83494/notes
  gitlab/request.rb:71:in `validate'
    raise error_klass, response if error_klass
  gitlab/request.rb:55:in `block (2 levels) in <class:Request>'
    validate response
  triage/triage/reaction.rb:22:in `post_request'
    Triage.api_client.post(path, body: { body: body }) unless Triage.dry_run?
  triage/triage/reaction.rb:12:in `add_comment'
    Reaction.post_request(path, body)
  triage/processor/availability_priority.rb:43:in `ensure_priority'
    add_comment("/label ~priority::#{default}")
...
(16 additional frame(s) were not displayed)
```

Story points: 2.0
no implicit conversion of nil into String in `RemindMergedMrDeviatingFromGuideline`

Sentry Issue: [TRIAGE-OPS-BN](https://sentry.gitlab.net/gitlab/triage-ops/issues/3237542/?referrer=gitlab_integration)

```
TypeError: no implicit conversion of nil into String
  time.rb:372:in `_parse'
    d = Date._parse(date, comp)
  time.rb:372:in `parse'
    d = Date._parse(date, comp)
  triage/processor/remind_merged_mr_deviating_from_guidelines.rb:58:in `latest_pipeline_is_recent_enough?'
    Time.parse(latest_pipeline_detailed.finished_at) >= (Time.now - 3600 * HOURS_THRESHOLD_FOR_STALE_MR_PIPELINE)
  triage/processor/remind_merged_mr_deviating_from_guidelines.rb:40:in `latest_pipeline_valid?'
    latest_pipeline_is_recent_enough?
  triage/processor/remind_merged_mr_deviating_from_guidelines.rb:20:in `applicable?'
    !latest_pipeline_valid?
...
(14 additional frame(s) were not displayed)
```

Story points: 2.0
Close issues that have the 'auto closed' label but are not actually closed

Due to a bug fixed at https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/1184, there are a number of issues in `gitlab-org/customers-gitlab-com` and `gitlab-org/license-gitlab-com` that have issues labelled with ~"auto closed" but are not actually closed.

Let's perform a once-off job to close this issues to keep things tidy.

Story points: 2.0
Consolidate the `Accepting merge requests` and `Seeking community contributions` hygiene policies

Kind of a follow-up to https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/1101 which can result in duplicate notes from the bot:

![Screen_Shot_2022-02-23_at_10.42.28](/uploads/83e74d18bbe73b24a90bf81ee9ff0070/Screen_Shot_2022-02-23_at_10.42.28.png)

I'll consolidate both labels automation in a single file.

Story points: 2.0
Make AppSec review comments for JiHu contributions in the CNG repository

We recently had [a JiHu contribution](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/886#note_843817808) that was properly labeled as ~"JiHu contribution" but did not get the AppSec comment. I'm guessing the CNG repository isn't something that triage-ops is monitoring. This may be intentional, so there may be a reason for this that I'm unaware of.

Ideally, AppSec would be getting pings for this repository as well.

If there's a reason why triage-ops doesn't/can't monitor this repository, we can try to figure out another way to get AppSec reviews of those MRs.

Story points: 2.0