A 4-Step Structure for Improving Your Pull Request Review Process for Better Code Delivery
Software Engineering Manager at Measurabl
Break through the friction by providing enough context for the reviewers to get up to speed. In other words: Give them context.
To achieve this, a strong pull request should have a clear structure including these sections:
An overview of what problem this change solves
The context that is important for understanding the blast radius of this change
How to evaluate the change and replicate in environments
- What’s the problem?
"It’s very easy to glaze over a diff and say 'okay, this looks good. Approved' and move on with your day." - Source
- Why is it important to them?
"A PR is a messy page of stuff. It means something to you, it means a little less to your team, and it means even less to everyone else." - Source
- Quality Assurance
"Make it easy for people to interact with the change in testing environments such as their local system or a shared development environment." - Source
"Screenshots, meeting notes, workflow recordings, concept documentation, async discussions, sample datasets for testing, known gotchas, etc." - Source
To wrap it up, think about your PR from the opposite viewpoint. If you were coming to it without understanding the context nor previous design preparation, what questions would you ask? Be prepared for those by providing answers and resources from the beginning.
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.