The intent of this epic is to consolidate epics and issues related to the **Forking Workflows Improvements** theme. Forking is a convenient and powerful simplification of cloning a Git repository to a different namespace, and creating a logical connection with the upstream project to simplify the process of sharing changes. Forking workflows are great in open source because they make it easy to manage access while still allowing anyone to contribute and giving individuals great flexibility to work in their own way until a change needs to be merged. These benefits also help private organizations, making it easy to control and manage the authoritative version, while allow freedom and flexibility internally to innovate and contribute. ### Vision Forking workflows should be fully supported in GitLab so that they can be used by open source projects and enterprises. #### Permissions for forks of internal and private projects Forks of private projects are private by default to protect the contents of the repository, but this creates workflow problems and is also incomplete for managing the lifecycle of the fork. - Users with write access to the upstream internal/private project should inherit write permissions to all forks so that they can effectively collaborate on merge requests https://gitlab.com/gitlab-org/gitlab-ce/issues/8935 - Forks of internal/private projects should be deleted if access is revoked to the parent project https://gitlab.com/gitlab-org/gitlab-ce/issues/45335 #### Workflow limitations There are a number of useful features that do not work across forks. These should limitations should be removed. - https://gitlab.com/gitlab-org/gitlab/-/issues/14615+ - https://gitlab.com/gitlab-org/gitlab/-/issues/21268+ - https://gitlab.com/gitlab-org/gitlab/-/issues/14293+ ### Links / references - Deduplication of objects across fork networks https://gitlab.com/groups/gitlab-org/-/epics/189