Category Direction - Groups & Projects

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.

Groups & Projects
Introduction and how you can help
Overview
Strategy and Themes
- Challenges
- Opportunities
1 year plan
Target Audience
Top user issue(s)

Groups & Projects


Stage	Data Stores
Maturity	Complete
Content Last Reviewed	`2023-11-24`

Introduction and how you can help

Thanks for visiting this category direction page on Groups & Projects at GitLab. The Groups & Projects category is part of the Tenant Scale group within the Core Platform section and is maintained by Christina Lohr.

This vision and direction is constantly evolving and everyone can contribute:

Please comment in the linked issues and epics. Sharing your feedback directly on GitLab.com or submitting a merge request to this page are the best ways to contribute to our strategy.
Please share feedback directly via email, or schedule a video call. If you're a GitLab user and have direct feedback about your needs for Groups & Projects, we'd love to hear from you.
Please open an issue using the ~"Category:Groups & Projects" label, or reach out to us internally in the #g_tenant-scale Slack channel.

Overview

Groups are a fundamental building block (a small primitive) in GitLab that serve to:

Group users to manage project authorization at scale
Create collections of users for security features like code owners and protected environments.
Organize related projects together
House features that cover multiple projects like epics, contribution analytics, and the security dashboard

Strategy and Themes

In 2023, our goal is to make improvements by extending Groups & Projects 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 Groups & Projects will allow us to solve a number of problems with the current experience:

Flexible hierarchies - We need to offer additional configuration options to allow enterprises to represent different types of organizations using groups, subgroups and projects.
Organizing content - Particularly during the creation process, users experience confusion around the nesting of projects within groups. We want to increase usability in this area.
Discoverability - Users currently have difficulties finding relevant content across the product, for example on list pages (including project, group, personal projects, and activity lists). At the same time, mechanisms to discover and explore new content are limited.
Deletion and recovery - Project and group deletion and recovery are currently inconsistent and need to be improved.
Archiving - Not all content can be archived and, once archived, the display and messaging of that content needs improvement.

1 year plan

Improving membership management by overhauling the Members page to clearly display:
- All invited members and groups, including their permissions.
Consolidating groups and projects. As part of this effort we are:
- Migrating basic project functionality to namespaces as a baseline for making functionality available at the group level. This includes functionality like starring, archiving, transfer or deletion.
- Unifying members and member actions on the UI and API level by consolidating memberships.

What is next for us

The Tenant Scale group is currently focusing on the Organization and Cell categories. This means that we are currently only considering improvements to Groups & Projects that benefit the maturity of either of these categories.

As a result of the ongoing consolidation efforts, we will be able to make existing project functionality available at the group level. The first iterations of this will include:

In addition, the new namespace framework also enables us to move functionality from the admin level to the group level:

As a first iteration of this, we will focus on migrating settings, so that group and project owners can have more control over their members.
We are planning further investments into group sharing to align the behaviour between groups and projects. Part of this effort will be to provide more visibility into group shares and to add an invitation flow for group shares.

What we are currently working on

What we recently completed

Comleted in 16.6

Ensure private group names are hidden from unauthorized users

What is not planned right now

The Tenant Scale team will not be responsible for migrating all features from a group or project to a namespace. We are building a framework and are documenting the process for features to be migrated. We collaborate with the respective teams to migrate existing functionality to namespaces.
Since we are focused on consolidating groups and projects at this time, we don't plan to make significant improvements to them, as this would create redundant work. Instead, we will have targeted initiatives on specific product areas such as the group and project dashboard to improve the experience holistically between groups and projects.

Target Audience

Groups and Projects are used by all GitLab users, no matter what role. However, there are some heavier users of Group and Project functionality:

Sidney (Systems Adminstrator) is often overseeing the GitLab implementation of their organization and manages access to Groups and Projects. Sidney is often involved in setting up and maintaining a Project and Group hierarchy that best represents the organizational structure of the company they work at.
Delaney (Development Team Lead) is primarily managing and coordinating the development team efforts within their team. Delaney often manages access to a specific subset of Groups and Projects representing their team or department.
Sasha (Software Developer) is primarily writing code, but uses Groups and Projects to collaborate with team mates. Sasha needs to understand who the members of a specific Group or Project are to involve the right team members when submitting merge requests or reviewing code.

Top user issue(s)

Here is a list of the top user upvoted issues with descending popularity: