- You are here:
- GitLab Direction
- Product Stage Direction - Manage
- Category Direction - Subgroups
The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Introduction and how you can help
Thanks for visiting this category page on Subgroups in GitLab. This page is being actively maintained by Melissa Ushakov. This vision and direction is a work in progress and sharing your feedback directly on issues and epics on GitLab.com is the best way to contribute.
Overview
Groups are a fundamental building block (a small primitive) in GitLab that serve to:
- Define workspace boundaries, particularly on GitLab.com, where a top level group frequently represents an organization
- Group users to manage authorization at scale
- Organize related projects together
- House features that cover multiple projects like epics, contribution analytics, and the security dashboard
Our mission
In 2020, our goal is to make improvements by extending Subgroups to help enterprise organizations thrive on GitLab.com. We will accomplish that by iterating on existing constructs and streamlining workflows to guide users to intended usage patterns.
Challenges
Historically, enterprise customers have gravitated toward self-managed GitLab as their favored solution. With the proliferation of cloud services, enterprises are looking for options to use GitLab with managed infrastructure. We need to provide a SaaS platform that can safely and securely house our customers while reducing the load and cost of having to manage and configure their own infrastructure.
Opportunities
Iterating on subgroups will allow us to solve a number of problems with the current SaaS experience:
- Increase isolation - We need mechanisms to isolate an organization from the rest of GitLab.com so that we can meet enterprise regulatory and security requirements. Creating clear workspace boundaries in GitLab.com will prevent users from unintentionally exposing users, projects, or other sensitive information to the rest of the GitLab.com instance. A top-level group should feel like a self-contained space where an enterprise can work independently of the rest of Gitlab.com. Users in a group owned by an enterprise should be able to complete all their day to day activities without leaving their organization's group.
- Additional control - On GitLab.com, user accounts and all associated details are owned by a user, not the groups they belong to. This is problematic for group administrators since they can't ensure the level of data integrity necessary for their audit and regulatory needs. We need to provide group administrators additional management capabilities for users in their group.
- Flexible hierarchies - We need to offer additional configuration options to allow enterprises to represent different types of organizationas using subgroups.
- Self-managed feature parity - In order to satisfy the needs of enteprise customers on GitLab.com, we need to offer an equivalent group and project administration experience as that in self-managed instances. To meet this goal, we must provide GitLab teams a framework to build settings and features and apply them to an entire group/project hierarchy.
Target audience and experience
Groups are used by all GitLab users, no matter what role. However, heavier users of Groups in terms of organization and management of projects and users consist of:
- Group Owners
- System Admins
- Team Leaders, Directors, Managers
- Individual contributors who predominantly work with GitLab's project management features
What's Next and Why
The issues below have been prioritized for short-term to help solve the problems outlined in the Opportunities section.
- Additional control
- Flexible hierarchies
- The Access and Plan groups will be collaborating to simply our data model by combining groups and projects. This will improve the user experience for users organizing many resources by expanding the functionality available at the group level. A simplified data model will also set the ground work for improving how resources are shared across groups.
- Self-managed feature parity
- Management of features and settings across project and groups is a challenge for GitLab administrators. We will be investing in workspaces to provide administrators with tools to effectively manage collections of groups.
What is Not Planned Right Now
- Group managed accounts - While we previously implemented group managed accounts as a solution for increasing isolation in Gitlab.com, we're not planning to continue in this direction. We would like to de-couple functionality that was only available in group managed accounts to allow for greater flexibility.
Maturity
This category is currently Complete. The next step in our maturity plan is achieving a Lovable state.
- You can read more about GitLab's maturity framework here, including an approximate timeline.
- Note that a
Complete state does not mean a category is "finished" and is no longer a priority. Even categories that are considered Lovable require continued investment.
Top dogfooding issues
🚨 GitLab Support Engineering: Isolation & Control Requirements
