But is it the most efficient way to ensure that level of quality?
PR-s influence the same code, so it is not enough to review PR-s individually anyway.
Maybe a weekly or monthly release would be a better unit for evaluation.
We have all kind of ways of producing diffs between branches, releases, tags, timestamps, etc?
Why would PR diffs be the most efficient unit to review?
Often PR-s are just a silly way to communicate between team members instead of just talking to each other. I.e., you sit in the same office and create and reject PR-s, when you could just say to you colleague: "if you do not like the name of that variable, feel free to change the name".
The main problem with the PR system is that changes to the code is not immediately committed to the branches that developers work on, so it limits cooperation between developers. You can still review commits to dev branches and if problems are found, you can fix them or in most cases undo them.
PR-s influence the same code, so it is not enough to review PR-s individually anyway. Maybe a weekly or monthly release would be a better unit for evaluation.
We have all kind of ways of producing diffs between branches, releases, tags, timestamps, etc? Why would PR diffs be the most efficient unit to review?
Often PR-s are just a silly way to communicate between team members instead of just talking to each other. I.e., you sit in the same office and create and reject PR-s, when you could just say to you colleague: "if you do not like the name of that variable, feel free to change the name".
The main problem with the PR system is that changes to the code is not immediately committed to the branches that developers work on, so it limits cooperation between developers. You can still review commits to dev branches and if problems are found, you can fix them or in most cases undo them.