I do what you are suggesting. Some other things: 1. Always a PR that is ready to merge (rebased properly). I should be able to read commit-by-commit and it all

I do what you are suggesting. Some other things: 1. Always a PR that is ready to merge (rebased properly). I should be able to read commit-by-commit and it all makes sense. 2. All reviewers are committed to review in < 24 hours, mostly the same day. Reviewing is considered an important high-priority activity for developers. 3. Keep them small - we reserve the right to reject a PR on size -- split it down (in reality, this is rarely done, because we know this) 4. Only make a comment if you think the code is unacceptable without the change. You can be convinced otherwise later, but no subjective comments -- it's either acceptable as is (no comment) or not. What I wish we did (and will probably try to make happen) 1. Work off a checklist. I have a couple of things I always check for -- e.g. i18n and accessibility, but we could do this a lot more. 2. Have a common understanding on what acceptable test coverage might be