4 Important Parts of Reviewing a Pull Request
Best practices for reviewers to make their life easier as repository maintainers.
Pull requests (PR) let you tell others about changes you have pushed to a branch in a repository (GitHub, Bitbucket, etc.). Once a PR is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes merged into the base branch.
1. Always acknowledge the PR.
As a maintainer or a reviewer, the best thing you can do is respond to the PR ASAP. Contributes may lose their interest if you keep them waiting so long, and it is not a good practice, especially if it is an open-source project.
It doesn’t matter if you do a review in an open-source or an organization project. Keep your contributors engaged, and if somebody tries to contact you privately to discuss a feature request or support need, politely direct them to public communication, such as comment or label section.
Here is one of an example from my personal experience from GitHub:
2. Identify the value delivering.
If you have a big PR queue, identifying the value added by each PR is so important. So you can sort it based on the value delivered. Each project has its prioritization based on various factors, concerning that you can prioritize the PR’s to take the necessary actions. Some prioritization would be like:
- Fixing an existing issue
- Security vulnerabilities
- A new feature that doesn’t affect the ongoing works
- Documentation updates, etc.
It is totally up to you to decide the priority and take the next step as reviewing the PR. If some PR is adding zero values or not getting a timely response back from the contributor, then it is ok to close those PRs with a justification (keep the conversation friendly).
3. Review the entire PR.
Everyone has their style of reviewing, or some organization has their review checklists to ensure that the changes are optimized, bug-free, and as per the code of conduct. Based on, those you need to verify all the changes in the PR. If it does not meet the standards, then don’t hesitate to ask for the Request Changes.
If your repository uses some Pull Request template or bot for automatic deployments or test executions, verify all these are also passing. If you are not using any of those, you can follow these standard practices to make the review easier.
It is good to document the processes. Writing things down is one of the most important things you can do as a maintainer. It makes it easier to say no when something doesn’t fit into your scope.
Also, very important to share the work or raise the hand whenever you need help within your maintainer community. It makes it easier for people to pitch in and leverage the support.
At last, approve the PR and Merge it when it is needed.
4. Appreciate the work done.
It is so important to appreciate the work done to the contributor. Even saying a simple “thank you” will encourage them for future contributions.
You can either automate it or comment on your words after merging the PR. Also, you can guide them to the help wanted issues in your comment section for keeping the contributors engaged with your projects.
Here is one of an example from my personal experience from GitHub:
“Ask a programmer to review 10 lines of code, he’ll find 10 issues. Ask him to do 500 lines and he’ll say it looks good.”
We might have heard this joke several times through social media. Sometimes I can even relate it from my personal experiences. But be honest with the review you are doing for a sustainable project.
Good luck!
