It's not enough to use groups to manage enterprise activity on GitLab.com; instead, we should consider how we might create a sub-instance level namespace within a GitLab instance. We can call this a GitLab Space or a GitLab Workspace.
The benefit to a customer would be removing the need to operate within the confines of a group. Instead, an enterprise could operate in a dedicated workspace, creating users (including admin users) scoped specifically to that workspace, isolated from the rest of the instance. This mechanism could also remove the need for group-level things and remove the barrier between self-managed and GitLab.com.
This is particularly valuable for GitLab.com but also valuable for self-managed instances seeking a barrier of separation between departments (for example, a large tech company might want a separate workspace for highly sensitive projects).
Whilst we can assume that all users would benefit from the Workspaces experience, the target personas we are focusing on are Team Leaders, Group Owners & System Administrators.
The current focus is to understand what an initial MVC might look like for a GitLab Space/Workspace that looks to try and solve the following problem: "As a Group Owner, I don’t have full autonomy over administrative decisions and tasks, as the group level permissions are not comprehensive enough." (example)."
Please see the GitLab Spaces epic.
For the moment, Workspaces 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: