Member-only story
Pull Request Etiquette for Reviewers and Authors
Be careful with those LGTMs
A pull request (PR) is a process when new code is reviewed before it should be merged to develop a branch or master branch in a Git repository like GitHub.
The author creates a PR, while a reviewer reviews a PR. A PR could be time-consuming, annoying, or even nerve-racking if done wrong.
Common PR issues are:
- The PR is too long. The PR is left open. No one reviews the PR.
- The reviewer keeps nitpicking minor mistakes. The author keeps repeating the same mistakes.
- The conversation is not responsive. Discussion becomes steamy. Nothing is resolved.
To nurture a healthy PR process, both author and reviewer should have a mutual understanding of common dos and don’ts in PR review.
Purely based on personal experience, the following 16 etiquettes could be used as guidelines for PR review in your team or organization.
1. Fast but Not Furious
The first key to a healthy PR process is responsiveness. In layman’s terms, fast! How fast? Fast enough so that no one feels like waiting for eternity.
How long do you take from getting a review request to opening a pull request? If your average time is more than an hour, you’re torturing the author. It might block him from working on the next story which relies on the PR.
It is the same for replying to comments. Either as a reviewer or as an author, you should keep the conversation actively going until the issue is resolved. However, don’t get furious if the other party is not responsive. They might be working on something more urgent.
Context-switch is expensive. Context-switch after a long period is more costly because you have to recall what you did. Developers have gold-fish memory when it comes to remembering what they wrote.
2. Small
The key to fast PR is small. A PR with one line change is sweet! No one wants to spend half a working day reviewing 1,867 lines of change. Some companies like Google have the culture of rejecting a PR if it has more than 500 lines.
