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.
Content last reviewed on 2023-02-21
This is the direction page for the Organization group which is part of the Enablement section of the DevOps lifecycle and is responsible for the following categories:
| Category | Direction | Description | Maturity |
|---|---|---|---|
| Subgroups | Direction Page | Groups represent collections of users or projects. | Complete |
| Projects | Projects are containers of resources used to host your codebase, track issues, plan work, and continuously build, test, and use built-in CI/CD to deploy your app. | Not Applicable | |
| User Profile | Directon Page | Users represent individuals using GitLab. | Not Applicable |
Thanks for visiting this direction page on Organizations in GitLab. This vision and direction is constantly evolving and everyone can contribute:
The Organization group focuses on creating a better experience for organizations to manage their GitLab experience. This includes making administrative capabilities that previously only existed for self-managed users available to our SaaS users as well, such as management of users and groups and supporting cascading settings. This also introduces a new concept for feature parity between projects, subgroups and groups. The result of this effort will be a more intuitive user experience for all our users towards more aligned behaviors throughout our product.
The video below contains a discussion with Sid on this topic outlining the problem and the concept of an "instance group". We have since moved away from the term "instance group" and are instead using the term "organization".
The video below gives a walkthrough of our MVC plan for Organization.
Today, GitLab's features exist at 3 levels:
| Level | Description | Example |
|---|---|---|
| Instance | Features for the entire instance. These are generally admin features (restricted to the admin panel or via a config like gitlab.rb), but not always (Operations Dashboard). |
LDAP, admin-level push rules |
| Group | Features configured and used at the group-level. These generally inherit behavior or objects down into subgroups (like epics, settings, or memberships). | Epics |
| Project | Features used at the project level. | Requirements Management |
This leads to a few problems:
While it would be ideal to have one way to build a new feature, most GitLab functionality should exist at the group level rather than the instance level at a minimum.
We should extract features from the admin panel into a new object called Organization that cascades behavior to all the projects and groups that are owned by the same user or organization.
The Organization group focuses on creating a better experience for organizations to manage their GitLab experience. This includes making administrative capabilities that previously only existed for self-managed users available to our SaaS users as well, such as management of users and groups and supporting cascading settings. This also introduces a new concept for feature parity between projects, subgroups and groups. The result of this effort will be a more intuitive user experience for all our users towards more aligned behaviors throughout our product.
Migrate basic functionality of groups and projects to namespaces while working with other teams to migrate their features to namespaces.
Move administrative features to the group level for group owners.
Consolidate & Cascade settings - this will allow cascading and enforcement of settings top down in the hierarchy.
Implement the top level namespace - this is similar to the existing top level group, but we will create a new landing page experience for organizations to easily view and action on different aspects of their groups, projects, users, settings and more.
When I am managing my DevOps lifecycle; I want to organize my people, content and value streams; so that I can deliver better software faster.
| Job statements | Maturity | Confidence | Source |
|---|---|---|---|
| When I am navigating a product; I want to find the content & features that are relevant to me; so that I can productively use the tool. |
|
Not validated | Issue |
| When I am defining my team's DevOps lifecycle; I want to manage users, teams and workflows; so that we can enable secure collaboration, standardize practices, optimize globally. |
|
Not validated | Issue |
| When my organization has a nuanced and nested knowledge architecture; I want to cascade content, settings and access top-down from parent to child organizations; so that my teams can collaborate, communicate, share information and maintain organizational standards. |
|
Not validated | Issue |
| When my organisation has a nuanced and nested knowledge architecture; I want to aggregate content bottom-up from child organizations; so that I can monitor activity, spot trends/bottlenecks and report to leadership on progress. |
|
Not validated | Issue |
Namespace is the logical object container in the code. Organization is the name for the top-level group.
Our current focus areas and engineering investment are broken down by category below, percentages represent how much engineering time on average is allocated in each milestone.
Our current focus is on consolidating groups and projects into one generic namespace container. The highest priority at the moment is to migrate basic project functionality to namespaces. This will enable us to make project functionality available at the group level.
Building onto the migration efforts described above, we are looking to provide functionality at the group level that was previously only available at the project level. First iterations of this effort will be to make the archiving and starring functionality available at the group level, which are some of the most requested features from our customers.
Another big pain point that our SaaS users have is the ability to control their users and groups, which exists in the admin panel for self-managed users. In order to overcome this and create feature parity, we will migrate administrative capabilities to the group and project level so that group/project owners can have more control over their members.
To ensure we can make progress in the other categories, we are currently deprioritizing work on the User Profile. We are supporting but not actively working on improvements.