Automatically add stage and groups labels to issues based on feature & category labels
In the vein of #144 (closed), this change add-team-labels.yml to add team (e.g. ~Manage), stage (e.g. "devops::manage") and stage group ("group::control") labels instead and add missing data for the missing teams, stages, stage groups, and feature labels.
The file has also been renamed to add-team-stage-and-stage-group-labels.yml.
Decisions
- Only the first detected stage/group will be applied to an issue.
- Stages/groups are evaluated in the order specified at https://about.gitlab.com/handbook/product/categories/#devops-stages. That means devopsmanage will take precedence over devopsplan, devopsplan over devopscreate and so on.
- That way we avoid adding multiple stages/groups to an issue, which would conflict with the
Ensure there's a single stage labeltriaging rule.
- That way we avoid adding multiple stages/groups to an issue, which would conflict with the
- The rule won't apply to issues that already have a group label. That means the group label can be changed manually to reflect which group is actually working on an issue for instance.
- We're only applying labels to the issues created in the last 2 days so that if there's any bugs in our automatic classification, we can fix it before we remove this condition and apply labels to all issues regardless of their creation date.
Expected impact with the "creation date >= 2 days ago" restriction
› grep "^/label" ce-triage.txt | cut -d' ' -f2-4 | uniq -c
1 ~Manage ~"devops::manage" ~"group::control"
3 ~Plan ~"devops::plan" ~"group::team
1 ~Create ~"devops::create" ~"group::source
3 ~Verify ~"devops::verify" ~"group::ci
1 ~Verify ~"devops::verify" ~"group::testing"
3 ~Verify ~"devops::verify" ~"group::ci
1 ~Package ~"devops::package" ~"group::package"
1 ~Release ~"devops::release" ~"group::supporting
1 ~Configure ~"devops::configure" ~"group::autodevops
2 ~Serverless ~"devops::configure" ~"group::serverless
1 ~Monitor ~"devops::monitor" ~"group::apm"
1 ~Quality
› grep "^/label" ee-triage.txt | cut -d' ' -f2-4 | uniq -c
1 ~Manage ~"devops::manage" ~"group::framework"
2 ~Plan ~"devops::plan" ~"group::team
1 ~Create ~"devops::create" ~"group::source
6 ~Verify ~"devops::verify" ~"group::ci
1 ~Monitor ~"devops::monitor" ~"group::apm"
3 ~Secure ~"devops::secure" ~"group::software
1 ~Geo ~"devops::enablement" ~"group::geo"
2 ~QualityExpected impact without the "creation date" restriction
From the dry runs:
| Labels added | CE count | EE count | Total |
|---|---|---|---|
| ~Manage devopsmanage ~"group::access" | 1,784 | 429 | 2,213 |
| ~Manage devopsmanage ~"group::measure" | 851 | 141 | 992 |
| ~Plan devopsplan ~"group::team planning" | 1,492 | 663 | 2,155 |
| ~Plan devopsplan ~"group::enterprise planning" | 1 | 43 | 44 |
| ~Plan devopsplan ~"group::certify" | 2 | 51 | 53 |
| ~Create devopscreate groupsource code | 2,384 | 455 | 2,839 |
| ~Create devopscreate groupknowledge | 3 | 0 | 3 |
| ~Create devopscreate ~"group::editor" | 205 | 64 | 269 |
| ~Gitaly devopscreate groupgitaly | 2 | 0 | 2 |
| ~Gitter devopscreate groupgitter | 0 | 0 | 0 |
| ~Verify devopsverify ~"group::ci and runner" | 1,449 | 335 | 1,784 |
| ~Verify devopsverify ~"group::testing" | 13 | 45 | 58 |
| ~Package devopspackage ~"group::package" | 138 | 48 | 186 |
| ~Release ~"devops::release" ~"group::core release" | 153 | 59 | 212 |
| ~Release ~"devops::release" ~"group::supporting capabilities" | 148 | 29 | 177 |
| ~Configure ~"devops::configure" ~"group::autodevops and kubernetes" | 424 | 66 | 490 |
| ~Serverless ~"devops::configure" ~"group::serverless and paas" | 50 | 1 | 51 |
| ~Monitor devopsmonitor ~"group::apm" | 43 | 20 | 63 |
| ~Monitor devopsmonitor ~"group::health" | 33 | 0 | 33 |
| ~Secure devopssecure groupstatic analysis | 2 | 55 | 57 |
| ~Secure devopssecure groupdynamic analysis | 3 | 23 | 26 |
| ~Secure devopssecure ~"group::software composition analysis" | 8 | 72 | 80 |
| ~Defend ~"devops::defend" ~"group::runtime application security" | 0 | 3 | 3 |
| ~Defend ~"devops::defend" ~"group::threat management" | 0 | 0 | 0 |
| ~Defend ~"devops::defend" ~"group::application infrastructure security" | 0 | 0 | 0 |
| ~Growth groupactivation | 0 | 0 | 0 |
| ~Growth ~"group::adoption" | 0 | 0 | 0 |
| ~Growth ~"group::upsell" | 0 | 0 | 0 |
| ~Growth ~"group::retention" | 0 | 0 | 0 |
| ~Growth ~"group::fulfillment" | 0 | 0 | 0 |
| ~Distribution ~"devops::enablement" groupdistribution | 14 | 3 | 17 |
| ~Geo ~"devops::enablement" groupgeo | 13 | 305 | 318 |
| ~Memory ~"devops::enablement" ~"group::memory" | 0 | 0 | 0 |
| ~"devops::enablement" ~"group::ecosystem" | 146 | 9 | 155 |
| Quality | 12 | 7 | 19 |
To do before merging
- Give a heads to let people know that they could receive a lot of notifications due to this new triaging rule:
-
Company call -
Slack channels: #development,#product
-
Open to see the problems with the first version of the change
## Impact of the first version of the change- From the dry runs that would add labels to approximately 7,519 CE issues and 2,092 EE issues.
- Of the 7,519 CE updated issues:
- 824 would have two Stage labels added.
- 19 would have three Stage labels added.
- Of the 2,092 EE updated issues:
- 307 would have two Stage labels added.
- 1 would have three Stage labels added.
Problem to solve
- Approximately 1,151 issues (CE + EE) would end up with multiple Stage labels, which would conflict with the
Ensure there's a single stage labeltriaging rule that would then only keep the last Stage label added.- The problem is that, the next day, the
Add team, stage and stage group labels for issues based on featuresrule would add back the multiple Stage labels and the process would continue forever until Category/Feature labels are removed so that only one Stage label could be mapped from the Category/Feature labels.
- The problem is that, the next day, the
Potential solutions
- A boring solution could be to add the auto updated label and only process issues that don't have this label so that at least we won't keep adding and removing Stage labels.
- A smarter solution could be to select the Stage label that would "win" based on the number of labels per Stage. For instance if an issue has ldap, oauth and epics, then only the ~"devops:manage" label would be added since two Category labels (ldap and oauth) are for this stage and only one (epics) for the ~"devops:plan" stage.
We could actually implement the first solution in this MR as a first iteration, and then the second solution in the next iteration.
Closes #151 (closed).
Edited by Rémy Coutable