Comment by callc
1 day ago
I’m dealing with similar issues.
It’s reasonable to come up with team rules like:
- “if the reviewer finds more than 5 issues the PR shall be rejected immediately for the submitter to rework”
- “if the reviewer needs to take more than 8 hours to thoroughly review the PR it must be rejected and sent back to split up into manageable change sets”
Etc etc. let’s not make externalizing work for others appropriate behavior.
Eight hours to review! Girlie how big are these PRs?
I can’t imagine saying, “ah, only six hours of heads down time to review this. That’s reasonable.”
A combination of peer reviewed architecture documentation and incremental PRs should prevent anything taking nearly 8 hours of review.
Agreed, if it takes 8 hours to review a PR, then the process is broken and you need to start talking before anyone starts writing code. I'd put the max window on maybe 30 minutes for a PR, otherwise we're doing something else, not a "last pass before merge into production".