I'd like this feature to reduce the management workload.

Going with the house metaphor, I don't want anyone eating in any room in the house, except the dining room. So I make a rule for the all the rooms in the house that there is no eating, then override that rule for the dining room. That requires 2 management steps. Right now, if I want to get to the same outcome I have to go to each room and make a rule that there is no eating, and skip over the dining room in setting this rule. That is now N-1 management steps (N being number of rooms in the house). Then if I remodel in the future and add an office, I have to go to the office and add the no eating rule. How it is now, the remodel requires another management step, but if this suggestion was implemented it would require no management steps.

I could build another house, but man, that's a pain, especially since my new room is completely relevant to my already constructed house. And the property developer will ask me "Why do you need another house for 1 room? Why can't you use the house you already have and just add on?", which, is a very valid question.

https://getsupport.atlassian.com/browse/PSSRV-131929

Came to this feature request since we hit same issue in our workflow and wanted this feature.  

@Richard Cross.  I think you nailed it right there — which user privilege should be allowed to refine policy.  In our case, we would want the project owner to set blanket policy and then for specific repos create an override.  Agreed, repo owner then does not have privilege to apply for specific override for individual repo. 

I agree it's annoying... but, to play devil's advocate for a moment,: it's surely also the entire point?

Look at it from the other point of view: a project owner who wants to set some "house rules" on merge approvals. If repo owners could simply ignore those requirements, then that model is unenforceable.

Isn't the correct solution simply to create your own project with different approvers, and move your repo there?

Yeah, this is a pain for us as well.
We want to be able to have default reviewers for the project and minimal approval of 1 or 2, but be able to overwrite that on on repo level.
Especially when we have a situation where one of the default approvers is myself. Then I cannot approve my own change, I cannot merge it if there is minimal approval of 1 on the project level and sometimes I have to be able to overwrite that if I'm alone and need to merge some code. Yeah, I can disable that on the project level temporarily, but it would disable it for all repositories.

Thanks for responding dhanle, that's helpful feedback!

Hey John,

The main use case is to have a set of default reviewers for the project and among those reviewers, have a minimal number of approvals.

Your suggestion of setting the minimum number of approvals, and then set the default reviewers doesn't work for 2 reasons

1. Minimum number of approvals is for anyone, not for the default reviewers
2. It doesn't scale to have to add default reviewers to every repo, and also to remember to add them to new repos under the project

To answer your questions:

1. The user who is asking for this feature is expecting it to act the same way as Merge Checks, or Minimum Approvals, you can disable/non-inherit on the repo level.  This is for special case repos that should be under the project for organization purposes, but should be excluded from the formal review process.
2. Yes, I brought that up with the user but it is a non starter since this project has hundreds of repos, and changing the project level will have a huge impact on user stories with those repos.
3. Yes! What you suggested, just an override button that says, Ignore Project Level Default Reviewers, that's all we ask

Hope this helps, I am happy to chat more if it is helpful

Thanks,

Donny Hanle

Just as a preamble: default reviewers was built specifically with the intent for it to be an additive set of rules.

It's possible to achieve a sort-of hybrid configuration that might suit; as pointed out in this Atlassian Community post, if the main point of having the project level default reviewers is to have a minimum number of approvals, then you could instead configure the Minimum Approvals merge check at the project level and configure the default reviewers at the repository level. Of course this means that repositories won't get default reviewers from the project level, but it does mean you get to override the minimum approvals.

It would be great to have the use case for this issue a little more fleshed out;

• why is it important that it's possible to override the default reviewers for some repositories in a project?
• Is it better to re-assess the project level configuration?
• What would a preferred solution look like?
  (Just off the top of my head, it would need to be an option at the project level to allow repositories to override rather than extend, and if that option were enabled, at the repository level the choice to extend or override.)

Without extra details it's less likely feature requests get actioned. The more details we have, the better we can implement features.

Regards,

John van der Loo
Developer, Bitbucket Server