Groups in GitLab are intentionally flexible. They're a great way of creating organization and access control, and do a good job of being a relatively generic object that's effective at both managing projects and organizing groups of people. In fact, our hypothesis is that these are the two big buckets that users tend to lean on groups for:
Managing what gets worked on (the code). An organization might make a new group for a dedicated initiative and all its child projects. This specific namespace helps manage code that spans multiple projects.
Managing the teams that do the work (the people). A group might be an organizational tool for a particular functional area (Sales, Marketing), and largely lean on issues to get things done.
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:
Whilst we can assume that all users would benefit from the Team experience, the target personas we are focusing on are Team Leaders, Group Owners & System Administrators.
Please see the Create and manage a team in GitLab epic.
For the moment, Teams are 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: