> sometimes you can note things as "nits", meaning, fine for now but maybe next time do it this way. That's actually one of the costs of PRs (or any kind of ma

> sometimes you can note things as "nits", meaning, fine for now but maybe next time do it this way. That's actually one of the costs of PRs (or any kind of mandatory and blocking code review). I've worked in places where the code review wasn't hard. People fixed these nits as a final step before pushing the whole thing to master. With blocking code reviews people either do that 'nit' thing, or keep the remark to themselves because it isn't worth fuzzing over. All code review processes have some degree of rubber stamping, but the mandatory ones have a bit more. Orthogonally, I feel that more reviewers makes the process and the results better. The best review process I've seen was slow as hell: (nearly) every team member would do (nearly) every code review. People would start riffing off of each other and actually learned from each other. You could actually get a good team-wide conversation going about the best approach to doing stuff a certain way.