### Problem * The way that groups, sub-groups, and projects currently behave does not work well for a large number users organize their teams and repositories. TL;DR: repositories are too tightly coupled to project management -- especially in most use cases outside of a mono-repo or where teams need to track their work in a single location across many repositories that don't fit neatly into a hierarchical structure. * We currently have a lot of requests to "implement `[insert existing project feature here]` at the Group level" as a way to try and solve some of this -- so we are basically duplicating capabilities that already exist at the project level but within the group. * When we do this, we end up not cleanly recreating the same experience at the Group level, resulting in defects, missing capabilities, or poor user experiences that then lead to a lot of rework and duplicated effort. A few simple examples: - you cannot export/import issues at the group level -- you must go to a project. - when bulk editing issues at the group level, only a few fields are available compared to those at the project level. - When looking at an issue board at the group level, then clicking on an issue that takes you down into a project, users frequently click back to the issue board tab only to find an empty, unconfigured issue boards. Real problem, but out of scope initially... * Additionally, creating "instance level" or "namespace" level issues, epics, etc. doesn't really solve the underlying root cause of gracefully handling "least access" permissions and allowing work to flow horizontally across siblings and vertically from parents to children. [Group Sharing](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html) was a great first step here, but customers are frustrated that it doesn't also share objects (namely issues) from Sibling A with Sibling B, when Sibling B just wants to manage all of its work items within Sibling B even though some issues exist in Sibling A. ### Customer Use Cases - [Video 1](https://drive.google.com/file/d/1kTigDaIILQk6y-Z1z4n7wN3DmNseN9Me/view?usp=sharing) (internal) - [Video 2](https://drive.google.com/file/d/1uXHxBKB--gTo6MfQ2glwjPcIpu5Sdi1E/view?usp=sharing) (internal) - https://gitlab.com/gitlab-org/gitlab/issues/207314 - https://gitlab.com/gitlab-org/gitlab/-/issues/8867 ### Proposal There are a lot of implications here, but on a high level, migrate Groups and Projects into the Namespace behind the scenes. Issues can roll up to parent Namespaces, etc. but also can be created and managed on the parent Namespace itself. Integration settings can be inherited by parent Namespaces or can be overridden on a per-project basis. Each Namespace can have its own wiki, etc. Not in scope for this epic... Once this basic structure is in place, we could improve the relationship of issues (and other things) among siblings. For example, Namespace A integrating well with Merge Requests from Namespace B. This would enable us to re-use the Namespace primitive and give the end user full control over what features they want to use depending on what they need at the time. This structure also makes it easier to scale out repositories separately from how project management within teams is conducted and vice versa. ### Key Benefits 1. We wouldn't have to maintain feature parity and duplication across different Groups and Projects.... 1. We would be able to more easily "templatize" Namespace patterns based on common use cases. 1. Simplifies the cognitive overhead of groups, subgroups, and projects. 1. Builds on a small primitive. 1. Makes it easier to maintain separation of concerns between code/repo namespaces and "team" namespaces. Not in scope for this epic... 1. Provides unlimited flexibility for teams to easily structure GitLab according to their needs -- and easily adjust it as their team grows without having to re-org the group/sub-group structure every 6-9 months. #### Current ```mermaid graph TD subgraph Instance GroupA["Group [/chocolate]"] --> Project1["Project [chocolate/cookie]"] GroupB["Group [/vanilla]"] --> Project2["Project [/vanilla/shake]"] end ``` #### Future ```mermaid graph TD subgraph Instance NameSpaceA["Namespace [/]"] NameSpaceA --> NamespaceB["Namespace [/chocolate]"] NameSpaceA --> NamespaceC["Namespace [/vanilla]"] NamespaceB --> Namespace1["Namespace [/chocolate/cookie]"] NamespaceC --> Namespace2["Namespace [/vanilla/shake]"] end ``` #### Improving feature discovery during onboarding  ### Links & Resources - [Sourcehut Hub takes a similar approach](https://sourcehut.org/blog/2020-04-30-the-sourcehut-hub-is-live/) - [Opportunity Canvas](https://docs.google.com/document/d/1a2xuEMAsWzPK-cb_wnS9DWh9YHXZLs34Lp7jdetODR4/edit) (internal)