Proposal: Add internal visibility level to GitLab.com
Problem
On self-managed GitLab instances, users can choose between three visibility levels for groups and projects:
- Public - everyone can see them
- Internal - only users bound to the instance can see them
- Private - only members of the group/project can see them
On GitLab.com, there are only two visibility levels that users can select from:
- Public
- Private
Because most enterprises do not want to make their work public for security reasons, the only option they have on GitLab.com is to make all groups and projects private. This creates a whole lot of problems around how users are able to navigate around the groups underneath a top-level group that belongs to an organization:
- Users cannot see all groups and projects that are underneath a top-level group.
- The only way for users to become part of a group is to be added directly to them.
- In order for group sharing to work, a group/project owner has to be present in both of the objects they want to link. Groups cannot simply request access to another group they are not part of, because they are not able to see it.
Organizations are not yet isolated enough from GitLab - the instance - to be able to have the same internal visibility option available to them as they have on self-managed instances. Internal on GitLab.com today would mean that all logged in users of GitLab.com would be able to see it, regardless of organizational boundaries. This essentially means that organizations moving from self-managed to GitLab.com are losing functionality and have to think very carefully about how they set up their organization in order for everyone to get the right level of access.
What would it take to give users internal visibility functionality on GitLab.com?
Proposal
1. Bind visibility to the top-level group
In this case, group visibility would be seen in the context of the top-level group.