Rollout plan to move from old "team" labels to "group:xxx" and "devops:xxx" labels
We need a list of steps to make sure data is not lost and properly deprecate the previous team labels.
Transition plan
We'll do it on a group by basis as the teams split into groups.
- We will wait until a given team has fully-spit, (reporting structure has changed with a dedicated manager) before asking the split teams to transition to group labels fully. In the meantime we will auto apply group and stage label on historical data. Please see roll out plan below.
- We allow
devops::xxx
to be mis-matched withgroup::xxx
where applicable. We just need to be aware that the numbers maybe odd when we compare group to stage throughputs. It may not be an accumulative number.- There will be edge cases, we should not look for a correlation of group level vs stage level throughputs. E.g. ~Documentation work in devopsplan which is not part of any group under devopsplan
- When working on shared frontend and backend components it is ok to just have a
devops::xxx
label if it spans multiple groups. - We have 2 version of the dashboard, as each team transitions to the new labels they should check that the numbers match roughly to their new dashboard.
Deciding which group label to use
In the spirit of "Everyone can Contribute" it's natural that members in a group will contribute to another devops stage and group. We should aim the definition and guideline to cover for the 20/80 (default accounting method) Optimizing for all edge cases will lead to complexity. There will always be edge cases
We should allow flexibility where some group::xxx
may not correspond to the correct devops::xxx
labels in the case where labelling was corrected by a human. Some backstage improvements may not have devops::xxx
but it should have the group::xxx
label that worked on and frontend / backend where applicable.
- By default (20/80) the MR from an author should belong to his/her
group::xxx
and direct parentdevops::xxx
- If a contribution happens cross team, let's leave it to the discretion of the EM/PM to change the
group::xxx
to reflect which group worked on it. They can also decide if they want to move over thedevops::xxx
as well or keep it to reflect the product area. - From an auto-labeling perspective, we will not override existing labels or if it was corrected by a human.
- MRs #141 (closed)
- Issues #181 (closed)
Given this, there should be enough flexibility and still achieve hygiene and reduce the number of labels we have.
For Issues. The labeling to a group label is being done on based on feature and category labels, not authors. So this should still be accurate when mapping to the direction
page.
You can see the backdrop work that @rymai has done in !122 (merged) which already has been reviewed/signed-off by the product team. Next iterations in #181 (closed)
For Merge Requests (concerning throughputs) this is where the unit of work is being done and the labeling by authors will help with engineering metrics. I see the flexibility of contributions happens here. This should be covered by what I outlined in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29714#note_183670507. My understanding is that MRs do not affect the content of the direction
page.
Testing with scenarios done with @gonzoyumo gonzoyumo/board-test#9
Mapping
-
~Create => devopscreate - New groupsource code
- New groupknowledge
- New ~"group::editor"
-
~Gitaly => devopscreate + groupgitaly -
~Gitter => devopscreate + groupgitter
-
~Manage => devopsmanage - New ~"group::access"
- New ~"group::measure"
-
~Plan => devopsplan - New ~"group::team planning"
- New ~"group::portfolio management"
- New ~"group::certify"
-
~Verify => devopsverify - New ~"group::ci and runner"
- New ~"group::testing"
-
~Package => devopspackage - New ~"group::package"
-
~Release => ~"devops::release" - New ~"group::progressive delivery"
- New ~"group::release management"
-
~Configure => ~"devops::configure" - ~"group::autodevops and kubernetes"
- ~"group::serverless and paas"
-
~Monitor => devopsmonitor - ~"group::apm"
-
Health => ~"group::health"
-
~Secure => devopssecure - groupstatic analysis & ~"Secure::Static and Dynamic Analysis"
- groupdynamic analysis & ~"Secure::Static and Dynamic Analysis"
- ~"group::software composition analysis" & ~"Secure::Software Composition Analysis"
-
~Defend => ~"devops::defend" - ~"group::runtime application security"
- ~"group::threat management"
- ~"group::application infrastructure security"
-
~Growth => devopsgrowth - groupactivation
- ~"group::adoption"
- ~"group::upsell"
- ~"group::retention"
-
~Fulfillment => devopsgrowth + ~"group::fulfillment"
-
New
Enablement
=> ~"devops::enablement"-
~Distribution => ~"devops::enablement" + groupdistribution -
~Geo => ~"devops::enablement" + groupgeo -
~Memory => ~"devops::enablement" + ~"group::memory" -
~Ecosystem => ~"devops::enablement" + ~"group::ecosystem"
-
No change
Rollout steps
-
Ensure that stage and group labels are inferred correctly !122 (merged). -
Ensure mapping is correct, #201 (closed) -
Remove threshold on auto labeling 1:1 mapping #211 (closed) -
Transition each stage and groups to their new labels. -
Archive the existing legacy "team" labels. => #254 (closed)