<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=224409) </details> <!--IssueSummary end--> <!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> In %"13.2" we'll be implementing the ability for group owners to [prevent forking outside of the group](https://gitlab.com/gitlab-org/gitlab/-/issues/216987). This resolves a pain point for GitLab.com customers but does not address additional pain points for self-managed users or users with nuanced needs around project forking controls and visibility. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Add an instance-level toggle to "prevent forking" or similar language. This toggle, if `enabled` would prevent any forking across the instance. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> We'll likely need to employ a similar mechanism as https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33923 to allow `admins` to reduce the scope of this inheritance only to compliance framework-labeled projects or some other identifier for use cases that do not require this broad action.