I will tell you what I do, your mileage might vary.

I try to keep my code changes small. I rather have 4 changes in four different PRs, than a single one. Have you ever opened up a PR, saw 25-100 files changed and you just moved on instead of going through it?

Also, I will add a small explanation of what I'm trying to solve, and if I did something "smart" I'll explain why.

Finally I keep a small list of people that tend to approve my changes fast and ping them if enough time has passed.

On the flip side when I see a PR, I will let people know that I'm looking at it OR that I will look at it at a certain time and they should ping me if they don't hear from me (approval or comments). Also I have compiled a checklist that I follow for my PRs which speeds up the process, at least for me.

My PR checklist has three sections, what I should evaluate, how I should communicate and how to write things in the PR itself. It's an accumulation from things I have seen in HN, the Google Code Review process, and reminders to myself. I tend to sound more authoritarian than I mean to be, so it's a reminder to be more gentle.

# Checklist
1. Design.
1. Functionality - Does the code do what it's supposed to do?
1. Complexity - Are individual lines, functions, classes too complex (aka hard to understand quickly).
1. Maintainability - too tightly coupled? Configurations hard-coded.
1. Comments - are comments actually necessary, they should explain why. Are there any comments/TODOs that can now be removed?
1. Documentation - has the appropriate documentation been updated
1. Good Things - comment on the good things as well
1. In general, favor approving a CR once it's in a state where it definitely improves the overall code health of the system being worked on, even if it's not perfect

## Communication
* Accept that many programming decisions are opinions.
* Ask good questions, don't make demands (what do you think about naming this `user_id`?).
* Good questions avoid judgement and avoid assumptions about the author's perspective.
* Ask for clarification ("I didn't understand. Can you clarify?").
* Avoid selective ownership of code (mine, not mine, yours).
* Avoid using terms that could be seen as referring to personal traits (dumb, stupid). Assume everyone is intelligent and well-meaning.
* Be explicit. People don't always understand your intentions online.
* Be humble (I'm not sure - let's look it up).
* Don't use hyperbole (always, never, endlessly, nothing).
* Don't use sarcasm.
* Keep it real. Be yourself.
* Talk synchronously. Post a follow-up comment summarizing the discussion.

## Reviewing Code Communication
* Communicate which ideas you feel strongly about and those you don't. (Nitpick: )
* Identify ways to simplify the code while still solving the problem.
* If discussions turn too philosophical or academic, move the discussion offline to a regular Friday afternoon technique discussion. In the meantime, let the author make the final decision on alternative implementations.
* Offer alternative implementations, but assume the author already considered them. ("What do you think about using a custom validator here?")
* Seek to understand the author's perspective.
* Sign off on the pull request with a or "Ready to merge" comment.
* Remember that you are here to provide feedback, not to be a gatekeeper.