Custom repository roles are not granular enough for some use cases

[manneorama]

As an internet bank, and I'm sure many other fields have the same burden, we live under certain rules and regulations. One of these rules is the 4-eyes principle, i.e nothing can ever be merged without an approved PR. Hence, we can't let teams modify the branch protection rules of their repo because then they could disable protection and thereby circumvent regulation.

A lot can be argued about trusting people to do the right thing of course, but unfortunately government agencies that audit the adherence to these rules and regulations aren't really interested in those arguments but rather they operate on the "can you or can you not circumvent this rule"-level.

We had high hopes for the Custom repository roles feature as it would remove a ton of admin work and maintenance around tooling related to this, as we hoped that we would simply be able to say "Allow all the things except modifying branch protection". But as it stands right now, allowing all things except the "Push commits to protected branches" checkbox when creating one of these roles removes a lot of other things that we do want our developers to be able to do. Such as delete, rename or archive a repo, or have full control over PR settings.

We hope that we're not alone in this use case, and that this can spark a discussion around the granularity of the repository roles. Thanks!