Allow 'Guest' role to read and pull from private repositories

Problem to solve

Make it easier for GitLab customers who host private projects to expose code to select third parties (for instance partners) who only read and clone said code.

Intended users

Enterprises who wish to share code with select third parties but not to the general public.

Partners of organizations who require limited access to that organization's source code.

Further details

Many organizations develop code that is not shared with the general public, but is shared with its partners. Currently, to avoid having customers pay for a per-seat license for each partner who needs to access - but not modify - said code, there is a 'Guest' user role which does not consume a license. However, the 'Guest' role is limited in that it only allows read access to internal and public repositories; reading and cloning from private repositories is not possible by 'Guest' users.

Allowing for an user role which does not consume a license yet still permits read and pull access from private repositories would allow GitLab's customers to pay just for the regularly-used licenses while retaining the flexibility of allowing read access to the code for infrequent limited-scope authenticated users such as partners.

This would make wise use of money customers pay for GitLab licenses while also increasing the breadth of the GitLab user ecosystem.

Proposal

Allow 'Guest' users read and clone access to private repositories.

Permissions and Security

The 'Guest' role would need "View project code" and "Pull project code" enabled.

Documentation

https://docs.gitlab.com/ee/user/permissions.html

Testing

A risk is that if existing customers have workflows designed around the fact that the 'Guest' role lacks access to private repositories, changing access rights to be more permissive for the 'Guest' role may lead to security issues whereby a previously inaccessible private repository becomes readable.

If this is a major concern, perhaps adding a brand new role such as 'Guest Plus' rather than modifying the existing 'Guest' role may be preferable.

What does success look like, and how can we measure that?

Immediate success metrics would be a specific enterprise customer being able to achieve their use case of sharing certain code with partners without incurring additional license fees for those partners. For long term success metrics, we should expect to see GitLab's footprint grow at organizations with such an use case.

What is the type of buyer?

This feature would apply to all buyer types from Individual Contributor through Executive.

Links / references

Comment from Sid in Slack discussion: https://gitlab.slack.com/archives/C3MAZRM8W/p1576005251055100?thread_ts=1575985246.045600&channel=C3MAZRM8W&message_ts=1576005251.055100