I don't see any other reason to require code reviews before a change can be merged.
> humans make mistakes
Then write unit tests, religiously. And pair. Or "... request reviews when they think it's necessary".
In my experience code reviews are not very good at catching mistakes.
> Different work in progress can be in conflict with each other.
Code reviews are the cause of too much work in progress, not the solution. Not the only cause.
> Reviews are a good way to learn from each other
In my experience, they are pretty bad at this. Pairing is vastly superior, or giving talks.
> reason to communicate with devs I might not otherwise communicate with
Then communicate with them. And if you want a review "... request reviews when they think it's necessary".
> Rejected
Exactly. That's not a useful form of interacting with your peers.
In the US, a SOC 2 audit of your org’s change management process is going to be a really bad time without this.
I don't see any other reason to require code reviews before a change can be merged.
> humans make mistakes
Then write unit tests, religiously. And pair. Or "... request reviews when they think it's necessary".
In my experience code reviews are not very good at catching mistakes.
> Different work in progress can be in conflict with each other.
Code reviews are the cause of too much work in progress, not the solution. Not the only cause.
> Reviews are a good way to learn from each other
In my experience, they are pretty bad at this. Pairing is vastly superior, or giving talks.
> reason to communicate with devs I might not otherwise communicate with
Then communicate with them. And if you want a review "... request reviews when they think it's necessary".
> Rejected
Exactly. That's not a useful form of interacting with your peers.