Develop process for triaging and prioritizing work that is not within a group
We have very clear definitions of the surface area that each group within GitLab works on. However the coverage is not exhaustive, there is some surface that is not covered within a current group's charter.
This can include low level frameworks like our object storage handling (gitlab-org/gitlab#27331), as well as some features like details of a project, or security issues (https://gitlab.com/gitlab-org/gitlab/issues/194354#note_269238144 - internal only).
The impact of this, is that issues can sometimes bounce around groups, causing unnecessary delay and potentially mis-prioritization.
We need to ensure that we are globally optimizing, rather than locally optimizing at the group level.
Proposed solution
Rather than try to implement groups dedicated to each part of the product that may not have a clear owner, we should develop a process to quickly triage these and ensure they have the right priority.
- Add the capability to triagebot to look for
~group::not_owned
issues. - Generate a weekly email summarizing the state, and highlighting any that need prioritization. It should go to stage and section leaders for global prioritization.
- Stage/Section leaders determine prioritization and which group can pick up the work. Group label and milestone is then re-assigned to the responsible group so it can be tracked in their boards/workflow.
Scope / Justification
We currently have 240 issues assigned to ~group::not_owned
: https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=✓&state=opened&label_name[]=group%3A%3Anot_owned. 94% are either un-triaged or assigned to %Backlog.