Moves Projects Category to Workspaces Group

Why

We don't move categories based on capacity. We put the categories in the stages where they logically fit, from a customer perspective. If something is important and the right group doesn't have capacity for it, we adjust the hiring plan for that group, or do global optimizations to get there faster. ref

Rationale:

• The Workspaces group was formed to accommodate the incoming headcount to focus on 1) providing a framework for moving Group and Project features to Namespace, and 2) wrapping all top-level Groups with a Workspace which will also be backed by Namespace.
• It will be more efficient, and logical from a customer perspective, for a single team to own the core "organizational constructs" within GitLab.
• The Workspace group will have greater autonomy and be able to move faster if they own Group and Project.
• Projects have never really been a natural fit for Plan and are even less so now that Plan is focusing on consolidating issues, epics, and requirements into work items.
• The Plan stage will continue to support the Workpaces group by moving Plan features to Namespace.

Approvals

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

• Chief Product Officer @sfwgitlab
• VP of Product @adawar
• The Product Director relevant to the stage group(s) @david
• The Engineering Director relevant to the stage group(s) @timzallmann
• Director of Product Design @vkarnes
• CEO

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

• Chief Technology Officer @edjdev
• Vice President of Development @clefelhocz1
• VP of Quality @meks
• Vice President of User Experience @clenneville
• The Product Marketing Manager relevant to the stage group(s)
  • @cfoster3
  • @cblake