Groups are a fundamental building block (a small primitive) in GitLab for project organization and managing access to these resources at scale. Like folders in a filetree, they organize like resources into one place - whether that’s a handful of projects all belonging to a backend team, or organizing a group of user researchers into one place to make access control and communication easier.
Since groups cover multiple projects, we also scope a number of features at the group level like epics, contribution analytics, and the security dashboard.
In 2019, our goal is to improve groups with improvements to access control, enhancements to the user experience, and by introducing a first iteration at a type of group specific for teams of people.
As groups are a GitLab-specific concept, it's considered a non-marketing category without a maturity level that can be compared to other competing solutions.
As with any category in GitLab, it's dependent on your ongoing feedback and contributions. Here's how you can help:
Currently, adding new members to groups is largely permissive. Since groups tend to organize many important instance resources, we want to give administrators tools to restrict access to group resources and ensure that group members are in compliance.
We’re also improving on group authentication strategies that enterprises need to be successful (especially important for GitLab.com). Please see the ~authentication category epic for more detail.
Currently, subgroups always inherit members from parent groups. Not being able to selectively remove subgroup membership from a top-level group makes groups challenging to organize, especially on GitLab.com - where most customers are represented by a single top-level group. These groups should have the ability to configure sub-groups with whatever visibility settings that are required.