Reconcile our team, group label definitions with our organization structure
What does this MR do?
A follow up from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25210
With us scaling and the team structure splitting up. The previous "Team" labels do not clearly represent the structure of people in a single team. https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/issue_workflow.md#team-labels
Definition of a "team" https://about.gitlab.com/company/team/structure/#organizational-structure
Teams: constitute departments and are made of a line manager and their direct reports e.g. the Security operations team within the Security Department
Definition of a "group" https://about.gitlab.com/company/team/structure/#groups
A group is any arrangement of people that is not reflected directly in our org structure.
As such a true "team" definition requires 2 labels a ~group::
and either ~frontend
or ~backend
(as applicable) There may be exceptions like ~gitaly
or ~gitter
which the ~group::
label alone represents a line manager and their direct reports.
This is also reflected in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25210#note_153982049 where we attempted to cleanup the labels a while back.
So you could tag an issue with
Monitor Group
&Frontend Group
and it would tell you that a person from theMonitor Frontend Team
did it.
Changes
- Mark previous "Team" labels for deprecation.
- List all
~group::xxx
labels in the list - Move UX and Quality to Department labels.
- Outlined the remaining "True" Team labels: ~Delivery ~Documentation
- Move frontend and backend to Specialization labels, per https://about.gitlab.com/company/team/structure/#specialist
Guidelines
- 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.
Given this, there should be enough flexibility and still achieve hygiene and reduce the number of labels we have.
Reason for deprecating previous "Team" labels
- From our org-chart https://about.gitlab.com/company/team/org-chart/ our previous taxonomy now spans multiple teams.
- E.g. ~Create now spans multiple teams.
- With the label mapping outlined in gitlab-org/quality/triage-ops#172 (closed) some old team labels map to the
~group::xxx
label and not the~devops::xxx
label.- For example.
- Gitaly => groupgitaly under devopscreate
- ~Gitter => groupgitter under devopscreate
- For example.
- Simplify the amount of labels used. We shouldn't have to juggle 2 labels that overlap in meaning. We should consolidate on one label and make sure our workflow can scale to accommodate scaling changes. Headcount and resource planning how also pegs on devops stages and groups. For example how
~Manage
is splitting up gitlab-com/www-gitlab-com!23846 (merged).
Rollout plan
Roll out plan to transition to the new group/stage labels:gitlab-org/quality/triage-ops#172 (closed)