<!--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=501277) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal We want to improve our way of working with MRs, specifically regarding approvals. To maintain a high-security standard, we enabled the “Remove all approvals” setting when a new commit occurs. It works reasonably well when one approval is required. However, it requires significant effort to obtain all approvals again when multiple approvers are involved based on ownership in CODEOWNERS. GitLab has a great option for this use case - Remove approvals by Code Owners if their files changed. But there are two problems with it: - This option doesn’t exist at the Group level, only at the project level. Because of this, it’s difficult to enforce. - If this option is enabled at the project level and the CODEOWNERS file doesn’t exist, GitLab will not remove any approvals, making it harder to implement centrally (we should differentiate projects with and without CODEOWNERS and apply relevant settings). Desired behavior is: - We enable the “Remove approvals by Code Owners if their files changed” feature on the instance or group level. - If the project doesn’t have a code owner file, it should fall back to “Remove all approvals.” Maybe we missed something, and it’s possible to implement such behavior? <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!-- 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: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->