Forks of private projects should inherit permissions from the parent project
Problem to solve
As the owner/maintainer of a private project that uses a forking workflow for development, if I revoke a users access to the project, they will still have access to their fork. This is particularly problematic on GitLab.com where the users account contains both personal and work projects:
- this requires a well intentioned user to manually delete on GitLab
- this makes it easy for an ill intentioned user to retain a copy of the project
Further details
Allow edits by maintainers is not enabled for Private projects. If permissions were inherited from the parent project to the fork, this could be enabled for Private projects.
It isn't possible to access CI pipelines of a private fork, which means an upstream maintainer can't help debug the failure. This would also be resolved.
The proposal would make GitLab and GitHub's forking models (https://help.github.com/articles/about-forks/) consistent:
Private forks inherit the permissions structure of the upstream or parent repository. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. This helps owners of private repositories maintain control over their code.
Proposal
As a user with access to a private project, when I create a fork, all users and groups with permissions to access the private project, should have the same permissions to access the fork.