I am quite sure I am not the first to run into this issue, so we’ll see how others react.
At the moment (and please correct me if I am wrong), you can only tell github that PR has to be reviewed before merging, or not. This black and white policy doesn’t really work in the real world for me and my colleagues.
Specifically, PR’s are not all painted the same color. Some are trivial, some are a little more complex, some touch things that should not be touched without a good plan and review. Allowing things to go through without review is dangerous for most orgs, obviously, but it would be nice to be able to define a scheme for review policy, such as classification of PR’s similar to incidents, P1, P2, P3, etc. P3’s are trivial changes that may require no review because they are, for example, documentation changes only. P2’s are more complex reviews that only require 1 review while they change something in the target, it’s not really something that can blow up in your face. P3 or higher are for changes that touch things that could make life difficult for people, like changing the docker defaults file and causing all docker agents to be restarted. Not good.
But right now, I don’t know we can do this kind of categorization.
Does this make sense to anyone else? I’m open to comments, flames, modifications of the strategy, whatever.