## Problem [Related FigJam board](https://www.figma.com/board/qaNvvTAiN1thkz4RgeXmDp/Transition-group-sharing-to-Teams?node-id=0-1&p=f&t=NdaIstziUBSYvasQ-0) Groups in GitLab conflate resource organization with access control. This dual purpose creates a fundamental issue: Resources (groups/projects) are owned by individuals rather than teams, leading to single points of failure, unclear accountability, and permissions that don't reflect organizational structure. The core problem: Individual ownership of resources means permissions are scattered across persons rather than teams, making it impossible to model real organizational structures where teams, not individuals, own deliverables. While we do a solid job on the former, we've got room to improve on the latter. Since groups do double-duty here and are relatively generic objects, we're losing an opportunity to refine specific features that might help people get work done. Specifics on where we see this evidenced: * Reporting. We have few views in GitLab that allow someone else in the company to get a birds-eye view of team activity. This is especially frustrating for managers, who lack a single place to answer questions like "what is my team working on?" and "how can I effectively manage resourcing now and for the future?". * Tim's sheet: https://docs.google.com/spreadsheets/d/1WVp-79ojhfJtjXYnpMWN0QpXU2HRXf09-1wMOL1liwQ/ * Access control. Requests to [share a group with a group](https://gitlab.com/gitlab-org/gitlab-ce/issues/33054) and allowing [project settings to inherit from a group](https://gitlab.com/gitlab-org/gitlab-ee/issues/5255) are needs that align well with the concept. What if we could define a team in GitLab and grant specific access controls and permissions to these teams? * Communication. Issues are terrific async communication tools, but there's an opportunity here to build even richer tooling for both async and real-time communication. The concept of a GitLab Team would provide a great foundation to build on. * Portfolio management and workflows. Triaging and assigning issues/code reviews can get a lot easier to manage if we're able to assign to specific teams. ## Proposal We separate groups used to manage people from groups used to organize work like so: ```mermaid graph TD Organization --> Top-level_group --> Project_1 Top-level_group --> Project_2 Organization --> Team_group --> Team_1 Team_group --> Team_2 ``` * In a way this is already possible today * Existing group containers can be used to build team * Teams would be optimized for what they are designed to do: organize members. All additional functionality would be removed from the group object except for `Group information > Members`. * Teams are built on the namespace framework We use the existing group sharing functionality to build links between teams and groups/projects like so: ```mermaid graph TD Organization --> Top-level_group --> Project_1 Top-level_group --> Project_2 Organization --> Team_group --> Team_1 Team_group --> Team_2 Team_1 -.-> Project_2 ``` * Links can be built from both ends: * A team can request membership to a group or project * A group or project can invite a team to become members * A team can be added to a project * A team can be added to a subgroup containing several projects. In that case, team members would get access to both the subgroup and the contained projects. ## Implementation When this epic is complete: - Resources (groups/projects) will be owned by Teams, not individuals - No individual 'Owner' role will exist at group/project level - Organization Owners can create Teams - Teams create and own resources - Team membership determines individual permissions - Migration tools will convert individual ownership to team ownership ## What does success look like? A group's Owning Team can add another Team to a group or project and provide access that way. ## What does this look like elsewhere in the Market? The standard seems to be a collection of individuals who are working together in an area to accomplish a set of goals. At this level you need to be able to manage general capacity, availability, ownership, etc. Conversely, a Group (in the market) functions more as a collection of permission and an access controls, very similar to how we handle them: * [JIRA Groups](https://confluence.atlassian.com/cloud/create-and-update-groups-744721627.html) * [Planview Groups](https://success.planview.com/Planview_PPM_Pro/150_PPM_Pro_Administrator_Documentation/030_Permissions/040_Groups%2F%2FTeams/005_About_Groups) * [Azure DevOps Groups](https://docs.microsoft.com/en-us/azure/devops/reference/process-templates/define-groups-teams-permissions-plug-in?view=azure-devops-2019) ## Open Questions * How does this relate to Members? Would team membership replace direct membership? * Should inviting a team to a team be possible? * Should we inform users that they've been added to a team? * Should we display team membership anywhere outside of the team details page? * Should we consider creating a Teams API as part of this epic? ## Designs - [teams_prototype.html](/uploads/51e41c1886161bcb29626a6a1a80a2f7/teams_prototype.html)