All changes to our code base should be peer reviewed, to increase knowledge sharing and quality of the codebase.
Great APIs make development easier. But it's hard to create great APIs.
When making changes to any APIs (external or internal), consider starting by creating a PR with only the API change, to ensure it is agreed upon before writing any supporting code (which might end up being wasteful).
Preparation sets your reviewers up for success.
Restrict the size of your pull requests. It's easier to review smaller changes, the review will be done quicker and with higher quality.
It's easier to review code with commit messages that make sense.
Follow the guidelines on Commit Messages.
Your PR descriptions should be an extension of your commit messages. Write about both what the commit changes, and how you implemented the change.
Before assigning someone to review, leave helpful comments in parts of the PR that you might want to highlight specificially (e.g. examples of a newly used patter or, a specific change that is essential).
Do a rebase on the latest master first, to ensure the code is compared to the latest and greatest version of the code.