I do what you are suggesting. Some other things:<p>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.<p>2. All reviewers are committed to review in &lt; 24 hours, mostly the same day.  Reviewing is considered an important high-priority activity for developers.<p>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)<p>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&#x27;s either acceptable as is (no comment) or not.<p>What I wish we did (and will probably try to make happen)<p>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.<p>2. Have a common understanding on what acceptable test coverage might be