Create a new community led stage and group

Why is this change being made?

GitLab is a broad platform with many features and functionality. Most of these have a specific owner and team that works on them. However, some do not. This is not obvious though, so users and even team members are unaware of this. These "empty groups" still own categories which get their own bugs, feature requests, and community contributions. Because it is non-obvious they are empty groups, there is friction when we are unable to address a request and have to reset expectations. Additionally, this means we have non-consistent handling of these categories from internal teams - some teams will try to address issues in these categories while others won't. Each makes their own choice since we do not have any consistent stance or policy on how to engage with these empty groups and unowned features.

To increase transparency of our work and correctly set expectations for the areas in these current empty groups, this MR creates a new stage & group, called "Community Led", to hold all current and future "empty groups" and their categories. The goal of this MR is to introduce this new stage to document our current state and transparently set expectations with users and the field. Additional MRs are expected to be created to further define processes associated with this stage. Specifically around handling security issues, p1 bugs, etc.

Categories in this group are areas that GitLab feels are valuable and we would like to have more in, but do not currently have a dedicated team assigned to and so will rely on the community to contribute to and grow. Categories in this stage:

• Do not have PM, engineering, UX, Quality, or other team members associated with it
• Have no current plans for new feature development and are not planning to action feature requests
• Align with GitLab's strategy and provide value to our DevSecOps platform (e.g. we intentionally want them in the product, rather than want to remove them)
• Rely on community contribution for new features they see valuable in the related space.
• Rely on community contribution to identify and fix any bugs in the related space.
• Rely on the security on-call team to triage and identify assignees to fix newly filed security issues.

It is an explicit intention that items in the community-led stage do not stay there forever. If there is enough interest from the community in a category, it should be picked up by a group and a team assembled to drive it forward. If after a period of time the community has not provided many contributed and GitLab has not given the category to a new team, we should seriously consider deprecating and removing the functionality of that category.

With the introduction of this new stage, 2 categories, Incident Management and On-call Schedule Management, are being moved to it.

Approval Process

Merge requests with changes to sections, stages and groups and significant changes to categories need to be created, approved, and/or merged by each of the below:

• Chief Product Officer (@david)
• PLT Leader relevant to the affected Section(s) (@steve-evangelista)
• The Director of Product relevant to the affected Section(s) (also Steve)
• The Director of Engineering relevant to the affected Section(s) (@timzallmann)
• Director of Product Design (@vkarnes) _Note: Chief Product Officer approval should be requested once all other approvals have been completed. To request approval, post the MR link in the #chief-product-officer channel tagging both the Chief Product Offcer and cc’ing the EBA to the Chief Product Officer.

The following people need to be on the merge request so they stay informed:

• Chief Technology Officer (@sabrinafarmer)
• Development Leader relevant to the affected Section(s) (@dennis)
• VP of Infrastructure & Quality Engineering
• VP of UX (@ampesta)
• Director, Technical Writing (@susantacker)
• Engineering Productivity (by @ mentioning @gl-quality/eng-prod) (@gl-quality/eng-prod)
• The Product Marketing Manager relevant to the stage group(s) (N/A)