Skip to content

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 with group::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 parent devops::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 the devops::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.

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

  1. ~Create => devopscreate
  2. ~Manage => devopsmanage
    • New ~"group::access"
    • New ~"group::measure"
  3. ~Plan => devopsplan
    • New ~"group::team planning"
    • New ~"group::portfolio management"
    • New ~"group::certify"
  4. ~Verify => devopsverify
    • New ~"group::ci and runner"
    • New ~"group::testing"
  5. ~Package => devopspackage
    • New ~"group::package"
  6. ~Release => ~"devops::release"
    • New ~"group::progressive delivery"
    • New ~"group::release management"
  7. ~Configure => ~"devops::configure"
    • ~"group::autodevops and kubernetes"
    • ~"group::serverless and paas"
  8. ~Monitor => devopsmonitor
    • ~"group::apm"
    • Health => ~"group::health"
  9. ~Secure => devopssecure
    • groupstatic analysis & ~"Secure::Static and Dynamic Analysis"
    • groupdynamic analysis & ~"Secure::Static and Dynamic Analysis"
    • ~"group::software composition analysis" & ~"Secure::Software Composition Analysis"
  10. ~Defend => ~"devops::defend"
    • ~"group::runtime application security"
    • ~"group::threat management"
    • ~"group::application infrastructure security"
  11. ~Growth => devopsgrowth
  12. New Enablement => ~"devops::enablement"
    • ~Distribution => ~"devops::enablement" + groupdistribution
    • ~Geo => ~"devops::enablement" + groupgeo
    • ~Memory => ~"devops::enablement" + ~"group::memory"
    • ~Ecosystem => ~"devops::enablement" + ~"group::ecosystem"

No change

  • ~Documentation - no change
  • Quality - no change
  • UX - 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)
Edited by Mek Stittri