Related: https://gitlab.com/groups/gitlab-org/-/epics/5957 ## Background _This epic was split into two pieces, with the other at https://gitlab.com/groups/gitlab-org/-/epics/5957+s. This was done to ensure the epic only reflected a single vertical slice of functionality, rather than combining multiples._ Compliance-minded organizations manage their GitLab namespaces against company policy to ensure the use of GitLab does not create gaps in their audit posture. One of the most common requirements for these organizations is separation of duties; one of the primary controls that exists within GitLab to support this requirement are merge request approvals. ## Problems to solve Tracking and managing [Merge Request approval rules](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html) across a large number of projects can be incredibly time consuming and lead to surprises during an audit if a configuration was not caught. Currently, group owners must go into every project and manage their configuration individually. This can be time consuming and is error prone. ## Intended users [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) ## Job statement > When restrictions are necessary, I want to configure an environment, so that I can ensure we are compliant. ## Proposal To avoid breaking changes the goal is to allow groups to define sensible defaults for their project's merge request approval rules without creating a situation where a merge request is stuck. The first iteration will be to allow for configuration of merge request approval rules for `All protected branches`. This work is being tracked in [this child epic](https://gitlab.com/groups/gitlab-org/-/epics/11451). Scoping the rules to only protected branches will allow us to refine the functionality without risking customers getting into a situation where an MR is stuck. After the initial iteration has been delivered, we will look at expanding the functionality to include more use cases. Is this a cross-stage feature? --- :handshake: ~"group::compliance" ~"group::source code" ~"group::code review" Who is the buyer? --- Organizations with thousands of projects to manage using ~"GitLab Premium" --- Have feedback on this feature? Please share your thoughts [here](https://gitlab.com/gitlab-org/gitlab/-/issues/285342).