<!--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=383114) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal Currently, the Group merge request approval settings are limited to root groups, or specific projects and basic approval settings. This feature would be far more useful if two things were true: - The current Merge request approvals settings were settable at any group, subgroup or project level. - If "default" reviewers could also be assigned at the group, subgroup or project level. Our team works on a fairly large micro-service application spread across a lot of reops/projects, organized into groups and subgroups. We do not manage things at a "project" level, we manage our project and process mostly at the sub group levels. I do like the idea of enforcing some rules across our "root" organization folder, but we tend to defer to each scrum or product team to allow tailoring rules to meet their individual workflow and preferences. Much of the day to day work for each developer frequently spans multiple projects(repos) with associated MR. We typically require that each MR gets approved by at least one peer. We also like to share the review process across the entire team. No, we do not expect the entire team to do a review, only that the 1st person who has some time to help with the open MR's. We moved from Bitbucket, which does allow defining default reviewers at the Bitbucket project level, and that was a great feature. One of our developers very creatively wrote a script to address this difference in GitLab. <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->