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 the Monitor 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 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.
  • MRs gitlab-org/quality/triage-ops#141 (closed)
  • Issues gitlab-org/quality/triage-ops#181 (closed)

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
• 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)