giseldo/neodataset huggingface dataset:
Look at current labels instead of added labels in PlanUxMrReviewSupport

The following discussion from !1111 should be addressed:

- [ ] @mvanremmerden started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/1111#note_836167763):  (+3 comments)

    > @rymai @markglenfletcher It seems like the script might not actually pick up items as expected, shouldn't it have been triggered for this MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80124#note_8195fb85c4f7c66c218e1213f8b96c5dc3c33a89

Story points: 1.0
TypeError: no implicit conversion of nil into String | triage/processor/remind_merged_mr_deviating_from_guidelines.rb:44:in `latest_pipeline_is_recent_enough?'

Sentry Issue: [TRIAGE-OPS-9J](https://sentry.gitlab.net/gitlab/triage-ops/issues/3184468/?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:44: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:18:in `applicable?'
    (!latest_pipeline_is_canonical? || !latest_pipeline_is_recent_enough?)
  triage/triage/processor.rb:38:in `triage'
    return unless applicable?
...
(20 additional frame(s) were not displayed)
```

I think this happens when the latest pipeline is still running. In that case, we should return `true`.

Story points: 1.0
Ping team members in MRs that are waiting for a review

## Proposal

1. Ping inactive reviewers on community MRs ready for review to either review or reassign to someone else.
   * Conditions:
     * MR has ~"Community contribution" and ~"workflow::ready for review"
     * MR doesn't have ~"automation:reviewers-reminded"
     * No activity on the MR in the last 7 days
     * MR has reviewer(s) assigned
1. Ping MR coaches on community MRs ready for review.
   * Conditions:
     * MR has ~"Community contribution" and ~"workflow::ready for review"
     * MR doesn't have ~"automation:reviewers-reminded"
     * No activity on the MR in the last day (i.e. after 1 day of inactivity, ping an MR coach)
     * MR has no reviewers assigned

In both policies, we hint to add ~"workflow::in dev" if some work from the author is actually required.

If the reviewer doesn't take any action, the policy won't fire again, unless ~"automation:reviewers-reminded" is removed.

These policies should ensure that the ball is rolling when a ~"Community contribution" MR is under a GitLab team member responsibility.

Story points: 2.0
Reactive reminder for merged MRs deviating from guidelines

## Objective

Provide feedback on merge request guidelines to minimize the opportunity of a ~"master:broken" when a merge request is merged that deviates from the guidelines at https://docs.gitlab.com/ee/development/code_review.html#merging-a-merge-request

### Proposal

When a merge request is merged that deviates from these guidelines a reminder should be posted to the event_user for the merge event.

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75808#note_830752842

Story points: 2.0
NameError: undefined local variable or method `label_names' for #<Triage::DefaultLabelUponClosing:0x00007f70...

# Error Details:
- Sentry event: https://sentry.gitlab.net/gitlab/triage-ops/issues/3178482
- First seen: 
2022-02-01T17:12:32+00:00
- Last seen: 2022-02-01T17:12:32+00:00
 - Event: 1
- Users: 0

Story points: 1.0
Job Failed #2016178858 - Discover

Job [#2016178858](https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/2016178858) failed for a89c849571a693cff8ffbd0bb9d2b7fa9e4f4d07:

### Trace

```
/builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/filters/votes_conditions_filter.rb:46:in `calculate': undefined method `>' for nil:NilClass (NoMethodError)
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:340:in `block in filter_resources'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:331:in `select'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:331:in `filter_resources'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:300:in `block in resources_for_rule'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/expand_condition.rb:13:in `each'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/expand_condition.rb:13:in `perform'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:277:in `resources_for_rule'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:181:in `block in process_rules'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:180:in `each'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:180:in `process_rules'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:75:in `block in perform'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:66:in `each'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/lib/gitlab/triage/engine.rb:66:in `perform'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/bin/gitlab-triage:18:in `block in <top (required)>'
	from /usr/local/lib/ruby/2.7.0/set.rb:328:in `each_key'
	from /usr/local/lib/ruby/2.7.0/set.rb:328:in `each'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/gems/gitlab-triage-1.21.0/bin/gitlab-triage:11:in `<top (required)>'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/bin/gitlab-triage:23:in `load'
	from /builds/gitlab-org/quality/triage-ops/vendor/ruby/2.7.0/bin/gitlab-triage:23:in `<main>'
```

It appears the response was incorrect. Following the API request results in

```
{"error":"milestone_id does not have a valid value"}
```

Story points: 1.0
Remove Accessibility Categories and Usability Testing Categories from automation

## Summary

In https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/95994, we have removed two categories: Accessibility testing and Usability Testing. 

I have already removed the category in categories.yml, and removed the labels after relabelling the issues with their correct label. I want to confirm that there is no other triage or reports we need to update with these category removals. 

### 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
* [x] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
* [x] (If applicable) Rename the old label by adding `[DEPRECATED]` at the end of the label name, like ~"CI/CD [DEPRECATED]". => I actually deleted the label :see_no_evil: 


/cc @gl-quality/eng-prod

Story points: 1.0
Update group label name from monitor to respond

## Summary

~"group::monitor" will be renaming to `~group::respond` with https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/96249. Label needs to be confirmed with https://about.gitlab.com/groups.json after the MR is merged. 

This should be a simple label rename with no migration like https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/845. 

### Action items

* [ ] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
  * [ ] 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.
* [-] (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 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
Ensure Severity label is applied for UX issues

From Eng Staff Offsite. We want GitLab Bot notifications to make sure we add severity to issues with these labels:
1. "Actionable Insight," 
1. "Low SUS Score," 
1. "UX scorecard-rec," 
1. "cm-scorecard-rec," 
1. "UX debt," 
1. "UI polish," 
1. "UX solution validation," 
1. "accessibility," 
1. "VP-UX Dogfooding," 
1. UX bugs

We will point to the UX severity guidelines in https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity

Story points: 3.0
Follow-up from "Generalize the policy to prompt for slipping check"

The following discussion from !1019 should be addressed:

- [x] @oregand started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/1019#note_756434396):  (+2 comments)

    > @rymai 
    > 
    > Are we able to conditionally act on these type of actions? i.e.
    > 
    > ```
    > if group::editor
    >   mention:
    >     - ericschurter
    > ```
    > 
    > Or can we dynamically pass a name to a policy perhaps?

Story points: 1.0
Increase default group label application for project/group MRs

## Objective

Increase the ~group::* label coverage to improve filtered MR searches inside `gitlab-org` and increase discoverability of MRs in team Merge Request reports

## Proposal

See discussion in https://docs.google.com/document/d/1yzHuosvykzb_kaldjGP9I6wxpNpMXdNEvEFBkHyZpXs/edit#bookmark=id.gnno3zgd2hh3

- Review merged MRs for `is_part_of_product` projects (maybe in Sisense?) to identify groups and projects that are good candidates to auto-apply labels

Story points: 3.0
Web service from this project isn't used, the one from triage-serverless is used instead

I realized that triage-ops deployment isn’t used so any changes that were merged after the merging of triage-serverless into triage-ops haven’t been deployed. I’m trying to figure out what needs to be changed. I’m wondering of maybe we should take the opportunity to deploy a new cluster with a new triage-ops.gitlab.com domain so that once it’s ready we can just add the DNS record and update the webhook URL to use the up-to-date cluster.

We could maybe take the opportunity to resolve https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/766 at the same time.

For reference, the K8s config was introduced by https://gitlab.com/gitlab-org/quality/triage-serverless/-/merge_requests/27/diffs.

Story points: 3.0
Override "infer group from MR authors" logic for Distribution team members

Distribution team was partitioned to two charters - Build and Deploy. This was reflected in team page data file, where departments now say `Distribution Build BE Team` and `Distribution Deploy BE Team`. Triage-ops, when inferring group labels from MR authors sanitizes these as `group::distribution build` and `group::distribution deploy`. However, those labels do not exist because the team still uses a single group label `group::distribution`.

So, we need an override from `group::distribution build` and `group::distribution deploy` labels to `group::distribution` label.

Story points: 1.0
Allow community contributors to request a review

Similar to https://gitlab.com/gitlab-org/quality/triage-serverless/-/issues/173 and https://gitlab.com/gitlab-org/quality/triage-serverless/-/merge_requests/181, we should allow anyone to request a review with `@gitlab-bot request_review`.

The command should probably post to `#mr-coaching` in Slack for now.

We should monitor the number of requests from community contributors.

Story points: 3.0
New policies to set default type labels upon issue/MR merged/closed event

The idea is to create policies for the `merge_request.merged` event, based on the one-off migrations that were performed by https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/944.

The description of the policies can be found at https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/731.

- Set triage-serverless~2779335 merged and closed issues & MRs without a `type::*` label to `~type::maintenance`
- Set triage-serverless~2278655 merged closed issues & MRs without a `type::*` label to `~type::maintenance`

Story points: 2.0
Job Failed #1737994920

Job [#1737994920](https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/1737994920) failed for 398bbf2d1872bb4cd0d6b25e17f5c63986923cd2:

```
  1) DevopsLabels DevopsLabels::Context#stage_for_group returns the stage name of the given group
     Failure/Error: expect(resource.stage_for_group('distribution')).to eq('enablement')
       expected: "enablement"
            got: nil
       (compared using ==)
     # ./spec/lib/devops_labels_spec.rb:694:in `block (4 levels) in <top (required)>'
     # ./vendor/ruby/2.7.0/gems/webmock-3.10.0/lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'
  2) DevopsLabels DevopsLabels::Context#first_group_for_stage returns the first group of the given stage
     Failure/Error: expect(resource.first_group_for_stage('enablement')).to eq('distribution')
       expected: "distribution"
            got: "distribution_build"
       (compared using ==)
     # ./spec/lib/devops_labels_spec.rb:682:in `block (4 levels) in <top (required)>'
     # ./vendor/ruby/2.7.0/gems/webmock-3.10.0/lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'
```

Story points: 1.0
Use JSON structured log for better parsing in GCP

GKE logging agent automatically parses JSON logs as structured log and they will be available as `jsonPayload`.

https://cloud.google.com/logging/docs/structured-logging

To start with, we could add the following keys to the log:
- `message`
- `severity`

Subsequently, we could add more metadata to the log, for example:
- the relevant processor
- sync (web request) or async (background jobs)
- duration
- etc

Story points: 3.0
Job Failed #1628339249

Job [#1628339249](https://gitlab.com/gitlab-org/quality/triage-ops/-/jobs/1628339249) failed for 7e33bd5ea2f855b6a8e8eea848e85a974b855829:

```
  1) DevopsLabels.teams_per_user username: "lulalala", expected_teams: ["fulfillment_provision", "license"] returns teams of user
     Failure/Error: expect(described_class.teams_per_user(username)).to contain_exactly(*expected_teams)
       expected collection contained:  ["fulfillment_provision", "license"]
       actual collection contained:    ["license", "license"]
       the missing elements were:      ["fulfillment_provision"]
       the extra elements were:        ["license"]
     # ./spec/lib/devops_labels_spec.rb:76:in `block (4 levels) in <top (required)>'
     # ./vendor/ruby/2.7.0/gems/webmock-3.10.0/lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'
Finished in 1.96 seconds (files took 1.17 seconds to load)
653 examples, 1 failure
Failed examples:
rspec './spec/lib/devops_labels_spec.rb[1:6:6:1]' # DevopsLabels.teams_per_user username: "lulalala", expected_teams: ["fulfillment_provision", "license"] returns teams of user
```

Story points: 1.0
Resolve edge case in which approval of a "draft" MR triggers a detached pipeline

When a maintainer approves a MR on gitlab, @danger-bot will automatically trigger a new pipeline, stating:

> To ensure full test coverage, a new pipeline has been started.

![CleanShot_2021-09-22_at_18.05.43_2x](/uploads/4cfe22672d42b877eaff27f1d89d9dd6/CleanShot_2021-09-22_at_18.05.43_2x.png)

However, if the MR is still marked as a "Draft", this new `detached` pipeline is [run against the source branch](https://docs.gitlab.com/ee/ci/pipelines/pipelines_for_merged_results.html) rather than against the merged result. I had erroneously presumed that the pipeline triggered upon approval would be against the merged result, and this resulted in gitlab-org/gitlab~3496950 :scream: 

When I merged gitlab-org/gitlab!69072, I:

1. clicked "approve"
1. clicked "mark as ready"
1. waited for the new pipeline to become visible
1. clicked "merge when pipeline succeeds"
1. a detached pipeline was run which did not include the latest changes from `master` and missed a test failure which would have occured against a merged result pipeline
1. the pipeline passed and the merged branch ended up breaking master.

Had I instead clicked "mark as ready" _before_ clicking "approve", the full merged result pipeline would have been created instead and this test failure would have been caught before it was automatically merged.

### Recommendation

This behavior _is_ documented, so it is certainly my mistake, but I think if it's possible for @danger-bot to trigger a full merged-result pipeline regardless of the draft state we should configure it to do so (or failing that, it should produce a **warning** saying that the MR is marked as a draft and that a full merged-result pipeline should be triggered.)

-----------

Original discussion from gitlab-org/gitlab!70746:

> > I was not cognizant of any behavior change for pipelines triggered within draft MRs
>
> Yeah, it's a slightly surprising behaviour, but it is [documented](https://docs.gitlab.com/ee/ci/pipelines/pipelines_for_merged_results.html) (emphasis mine):
>
> > When the merge request can’t be merged, the pipeline runs against the source branch only. For example, when:
> >
> > * The target branch has changes that conflict with the changes in the source branch.
> > * The merge request **is a Draft merge request**.
>
> ---
>
> > The pipeline was triggered by `@danger-bot` automatically upon my approval of the MR, so that’s why it doesn’t show me as the triggerer.
> >
> > Do you think there an actionable issue here @markrian?
>
> That does sound like an edge-case bug in our `@danger-bot` tooling, yes (i.e., when the MR is `Draft`). Do you know where we might file an issue or MR for this?

Story points: 3.0
Consider cleaning up left-overs from the Knative integration

It looks we still have some left-overs from Knative:

- https://gitlab.com/gitlab-org/quality/triage-serverless/-/serverless/functions
- https://gitlab.com/gitlab-org/quality/triage-serverless/-/blob/master/serverless.yml
- https://gitlab.com/gitlab-org/quality/triage-serverless/-/blob/master/config/triage-virtual-service.yaml
- [Screen_Shot_2021-09-16_at_16.30.55](/uploads/5b0065b5fcf4a8f29eefab18354bf965/Screen_Shot_2021-09-16_at_16.30.55.png)

Story points: 3.0
Delay pinging AppSec team for JiHu contributions after first approval

Following up https://gitlab.com/gitlab-org/quality/triage-serverless/-/issues/125, this is brought up from https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/90253#note_677426770

## Problem

If we ping the AppSec team too early in the life cycle of a merge request, chances are AppSec team can review too early and the review becomes outdated quickly, therefore a complete re-review might be needed later.

## Proposal

Given that it's difficult to shift the ping after the "last" approval, we can at least shift the ping after the "first" approval.

Below was copied and edited from https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/90253#note_677426770

* MR gets submitted
* Bot makes [the unresolved thread](https://gitlab.com/gitlab-org/quality/triage-serverless/-/merge_requests/145/diffs) that acts as a blocker to merging until AppSec can review it (but does not `@-mention` the AppSec team yet)
* Reviewers/maintainers go through the MR, request some changes, eventually approve it
* Once approved by the reviewers/maintainers, automation comments in that unresolved thread and pings the AppSec team for a ~~{-final-}~~{+follow up+} approval

## Implementation

With https://gitlab.com/gitlab-org/quality/triage-serverless/-/merge_requests/153 where it can leave a unique mark in the comment, and a way to detect if the unique mark is already being left, we can extend this so that it can find the original thread and attach new comments in the thread.

* Wrap the first AppSec thread with a unique mark
* When we receive an approval, find the above thread with the unique mark
* Comment and ping AppSec team on the thread
* (Bonus) Make sure the thread cannot be resolved before AppSec team member is pinged!
* (Bonus bonus) Make sure that only team members can resolve the thread!

## Question: Final approval?

If we may find a good way to determine what is the "last" approval, we can as well make AppSec get pinged after that so AppSec team can be the last one to approve. This will be more ideal because we can make sure there's no loophole that AppSec team review can get outdated.

We can as well think about making this process more formal so maintainers can just follow that rule manually.

## Question: triage-ops?

Can we do the same for triage-ops?

Story points: 2.0
One-off migration for old types to new scoped types

1. Remove `~type::feature` when `~type::maintenance` exists - based on both labels being present after rename in https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/1003
1. Set ~security open, merged and closed MRs and open issues without a `type::*` label to `~type::maintenance`
1. Set ~documentation open, merged closed MRs and open issues without a `type::*` label to `~type::maintenance`

### Questions

- Where should ~documentation be defaulted to?

Story points: 3.0
Update triage-ops type label references

As apart of https://gitlab.com/groups/gitlab-org/-/epics/6622

Update the following references:

- [ ] https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/lib/untriaged_helper.rb
- [ ] https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/template/team-summary.yml.erb
- [ ] Probably more

Story points: 2.0
Handle ~group::not_owned label for "Untriaged community merge requests" policy

## Problem

In reports like https://gitlab.com/gitlab-org/quality/triage-reports/-/issues/4457 MRs with label ~"group::not_owned" often have missing stage labels.

Those MRs, although properly labelled otherwise, still show up in reports because stage label is missing if MRs changes span multiple stages (hence ~"group::not_owned").

## Proposed solution

Make this specific policy (https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/stages/report/untriaged-community-merge-requests.yml#L18) aware of the following condition:
* Skip MR for the report if the MR has ~"group::not_owned" and stage label is missing

Story points: 2.0
Update Author Label Inference Docs and Order

In a recent [Engineering Productivity team meeting](https://docs.google.com/document/d/1yzHuosvykzb_kaldjGP9I6wxpNpMXdNEvEFBkHyZpXs/edit#bookmark=id.nni8n0dmw9v6) we discussed how the author label inference can conflict with rules like the Feature Flag rules.

We decided that we should modify the order to have author inference be after Category inference and update these docs:

- https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#group-labels
- https://about.gitlab.com/handbook/engineering/metrics/#stage-and-group-labels

Story points: 3.0