giseldo/neodataset huggingface dataset:
Triage issues are polluting issue search in gitlab-org/gitlab

### Problem to solve

When searching through issues in [gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab), it common for the results to contain many triage issues - sometimes an overwhelming number.  This is not desirable.  Triage issues have little or no value as search results.  Generally users (internal and external to GitLab) would prefer to see the underlying issues that these triage issues refer to, but the triage issues are so keyword-rich they are crowding out those higher-value search results.

### Proposal

Triage report issues should be created in [gitlab-org/quality/triage-reports](https://gitlab.com/gitlab-org/quality/triage-reports), not in [gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab).

### Related links

- As recently as %12.4, issues for "Automatically rescheduled issues" and "Automatically rescheduled merge_requests" ([example](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=%E2%9C%93&state=closed&search=automatically+rescheduled)) were also crowding search results.  Those issues were apparently discontinued or moved elsewhere.

### Screenshots

<details>
<summary>A real search query returning triage issues as 4 of the top 6 results</summary>
![Screen_Shot_2020-09-04_at_12.20.37_PM](/uploads/016d6d981b96dd3b094bfe208081a77f/Screen_Shot_2020-09-04_at_12.20.37_PM.png)
</details>

<details>
<summary>A real search query returning triage issues as 3 of the top 6 results</summary>
![Screen_Shot_2020-09-04_at_11.35.43_AM](/uploads/62e5623ddbf9e290bf6a1faae3852d0a/Screen_Shot_2020-09-04_at_11.35.43_AM.png)
</details>

Story points: 1.0
Consider inferring stage/group labels from category labels for MRs as well as issues

As suggested in https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/506#note_405199143, given that we now set stage/group labels based on the author in the `pre-hygiene` stage (https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/.gitlab/ci/pre-hygiene.yml), that means it should be safe to infer stage/group labels based on category labels in the `hygiene` stage.

Story points: 2.0
Investigate why some issues did not get section labels

This was brought up at https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/528#note_398105857

* https://gitlab.com/gitlab-org/gitlab/-/issues/233112
* https://gitlab.com/gitlab-org/gitlab/-/issues/225466
* https://gitlab.com/gitlab-org/gitlab/-/issues/218642

Story points: 1.0
Triage Reports are not created for week of 2020-07-20

Team triage reports are not being created. I suspect the same issues as https://gitlab.com/gitlab-com/gl-security/abuse-team/abuse/-/issues/252

This issue is to investigate the root cause and get triage-reports created. 

## Actions

- [x] Announce issues in #product, #development, #eng-managers - https://gitlab.slack.com/archives/C0NFPSFA8/p1595258572124700
- [x] Manually create team triage reports
  - [x] `gitlab-org/gitlab`: https://gitlab.com/gitlab-org/quality/triage-ops/-/pipelines/168898689 and https://gitlab.com/gitlab-org/quality/triage-ops/-/pipelines/168900258
  - [x] `gitlab-org/gitaly`: https://gitlab.com/gitlab-org/quality/triage-ops/-/pipelines/168899495
  - [x] `gitlab-org/gitlab-runner`: https://gitlab.com/gitlab-org/quality/triage-ops/-/pipelines/168899804

Story points: 2.0
Remove the rules for removing `group::not_owned`

The following discussions from !537 should be addressed:

- [ ] @godfat started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/537#note_366305619): 

    > Can remove this after one-off is done.
    > 
    > Or maybe we can keep it for a day, and remove tomorrow after it ran in schedule?

- [ ] @godfat started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/537#note_366305633): 

    > Can remove this after one-off is done.
    > 
    > Or maybe we can keep it for a day, and remove tomorrow after it ran in schedule?

Story points: 1.0
`gitlab-triage` release process to include bumping version used by `triage-ops`?

`triage-ops` now uses the `gitlab-triage` version from the Gemfile:
- https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/521/diffs

So it's possible that the automated runs will not pull and install the latest version of `gitlab-triage` if we exceed the rule.

Should we make it part of the `gitlab-triage` release process to bump the version here in `triage-ops`?

Story points: 1.0
Make the idle merge requests report easier to navigate

Following up from https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/486#note_358196219

- Update the description to explain why we don't have direct links
- Use backticks for full URL
- ~~Add a section in the bottom and let people to copy and paste into another comment box, hit preview, here you go, links for you~~

```
- gitlab-org/gitlab!28949
- gitlab-org/gitlab!28949
- gitlab-org/gitlab!28949
```

Story points: 1.0
Reports for Community merge requests requiring attention for Secure analyzers

Within the Secure Sub-Department we get many `~"Community contribution"` MRs. We would like a report similar to what was set up for GitLab EE (example at https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58131)

It looks like a related initiative was created within https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/271 that may have extended to more projects. A challenge regarding reviewer roulette was mentioned. 

## Iteration 1

- [ ] Create a report for all of `security-products` groupo MRs + ~"Community contribution" that is similar to the community-merge-requests policy and assigned to @nmccorrison @twoodham @gonzoyumo @sethgitlab: https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/477#note_343589797

## Dynamic Application Security Testing (DAST)
1. https://gitlab.com/gitlab-org/security-products/dast (to be moved into `https://gitlab.com/gitlab-org/security-products/analyzers/dast` - per this [comment](https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/477#note_350220388))

## Static Application Security Testing (SAST)
1. https://gitlab.com/gitlab-org/security-products/analyzers/tslint
1. https://gitlab.com/gitlab-org/security-products/analyzers/secrets
1. https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs
1. https://gitlab.com/gitlab-org/security-products/analyzers/sobelow
1. https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex
1. https://gitlab.com/gitlab-org/security-products/analyzers/gosec
1. https://gitlab.com/gitlab-org/security-products/analyzers/kubesec
1. https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan
1. https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan
1. https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit
1. https://gitlab.com/gitlab-org/security-products/analyzers/brakeman
1. https://gitlab.com/gitlab-org/security-products/analyzers/bandit
1. https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder

## Dependency Scanning
1. https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium
1. https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven
1. https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-python
1. https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven-plugin
1. https://gitlab.com/gitlab-org/security-products/analyzers/bundler-audit
1. https://gitlab.com/gitlab-org/security-products/analyzers/retire.js

## Container Scanning
1. https://gitlab.com/gitlab-org/security-products/analyzers/klar

## Shared
1. https://gitlab.com/gitlab-org/security-products/analyzers/common

Story points: 2.0
Obsolete group: anomaly detection

## Summary

* ~"group::anomaly detection" should no longer be used.

### Action items

* [x] (If applicable) Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>.
* [x] (If applicable) Label migration on existing issues and merge requests: apply the new label to opened & closed issues, and open & merged merge requests.
  * [ ] 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.
* [x] (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
Obsolete group: runtime application security

## Summary

* ~"group::runtime application security" should no longer be used.

### Action items

* [x] (If applicable) Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>: https://gitlab.com/gitlab-org/gitlab-insights/-/merge_requests/195
* [x] (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.
* [x] (If applicable) Delete the old dashboard views using the deprecated labels.
* [x] (If applicable) Update the group triage report definition to use the new label.
* [x] (If applicable) Update the group label's description to refer to the new Stage.

/cc @gl-quality/eng-prod

Story points: 2.0
Obsolete group: attack surface

## Summary

* ~"group::attack surface" should no longer be used.

### Action items

* [x] (If applicable) Dashboard creation: create or update the stage/group in <https://gitlab.com/gitlab-org/gitlab-insights/blob/master/lib/gitlab_insights.rb>: https://gitlab.com/gitlab-org/gitlab-insights/-/merge_requests/195
* [x] (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.
* [x] (If applicable) Delete the old dashboard views using the deprecated labels.
* [x] (If applicable) Update the group triage report definition to use the new label.
* [x] (If applicable) Update the group label's description to refer to the new Stage.

/cc @gl-quality/eng-prod

Story points: 2.0