How to get your pull requests approved more quickly

TL;DR The fewer reviews necessary, the quicker your PR gets approved.

Code reviews serve an essential function on any software codebase. Done right, they help ensure correctness, reliability, and maintainability of code.

On many teams, and certainly on open source projects, these reviews are done asynchronously via pull requests. A developer writes code, submits a pull request (or “merge request”), and waits for review. They might start another ticket or go catch up on email (the asynchronous nature of this is fine, and often a necessary feature of distributed teams, but can lead to a lot of context switching and increased cycle times).

Ideally, the code review gets done quickly, everything looks great, and the PR gets approved. The developer perhaps then merges the change to the main branch, the pipeline starts, and the developer can move on to the next task.

In the real world, it can take a while to get this approval. Teams are often responsible for a wide set of code across multiple repositories. It can take a while to get your PR approved from somebody that knows this particular codebase. Folks that know that code are often in meetings, working their own development tasks, handling questions, etc. So often you will wait hours or even days until somebody gets a chance to review your code.

So when the reviewers do turn their attention to your code, you want it to be ready. Context shifts are difficult for folks on both sides of the review. The way to get your changes approved and merged quicker is for your change to require fewer reviews.  Everything else flows from this point!!!

1. Start off on the right foot

You don’t want to start your trip to Alaska by driving south (unless you live in the North Pole, in which case, I have questions).

As you begin, if you aren’t sure of the overall structure of the change, perhaps request a quick chat / pair programming session with somebody on the team that can help you with that. This will help your change get off on the right foot.

2. Before requesting review

Before you request the PR review, a few quick checks can help:

1. Ensure the CI build is passing. If the build is not passing, you are guaranteeing that changes will be requested.
2. Consider how your change will be tested. If possible, let’s write or update a test. (If not — why is it not testable? This is an opportunity for improvement.)
3. Look at the diff in detail. Correct anything that seems inconsistent. In other words, self-review before you ask others for review.
   1. Perhaps there are some inadvertent whitespace changes, unused variables, new unused functions, etc. (If these are not caught by the CI tool, perhaps this is an opportunity to add a linter into the process)
   2. Perhaps you inadvertently committed a file you did not mean to?
   3. Perhaps you added configuration that applies to one environment, or cloud region of your application. Did you also add it to the other environments/regions?

3. Creating the PR

The point of the pull request is to sell your change to the team! Explain why your change is correct, safe, and valid.

1. Enter a decent title summarizing the change. The PR title should not simply be the name of the branch (the default for GitHub PRs with multiple commits — think davidnortonjr patch 5)
2. Don’t leave the description blank – this is your chance to describe what your change does, link to supporting documentation, other PRs, GitHub issues, etc.
3. If there’s anything confusing or nonintuitive in the change, explain why either in code comments, or a GitHub comment on the diff.

4. Making requested changes

If all goes well, you get a green check mark. Often, however, changes will be requested. That’s OK! After you make the requested changes…

1. Go back to step 3 and do another self-review. Sometimes new issues sneak in.
2. Re-request review so folks know it’s ready—often the reviewer doesn’t notice the email notification that a commit was pushed, or they aren’t sure whether that one commit made all of the requested changes. Better to mark the review as complete.

Hopefully this will help you and your team reduce your cycle times and get your code to production more quickly! If you have any thoughts on this, please reach out!