How to address and prevent unreviewed PRs
Reviews affect both quality of code and delivery. Unreviewed PRs slows the cycle time of the team, creates bottlenecks in the delivery pipeline, and if done in a rush can hurt the quality of the review and thus quality of the code that is merged and released.
How to find unreviewed PRs
Unreviewed PRs can be filtered out in the Pull Request screen.
How to address unreviewed PRs
Set up Slack alerts for timely reminders
Daily Slack alerts can notify the teams in case any PRs were merged without review.
Haven't connected Slack? You can read how to here: How to integrate Slack with Hivel
Corrective Action: Post-merge Review
Start by conducting a thorough review of the already merged PRs. This should be done by a senior developer or a team lead to ensure that no critical issues were introduced. If the review identifies any issues or improvements, create new PRs to address them. Ensure these are reviewed promptly.
Branch Protection Rules
Implement branch protection rules in your version control system (e.g., GitHub, GitLab). Require that all PRs must be approved by at least one or more reviewers before they can be merged.
Improve PR Workflow
Set Clear Guidelines: Establish clear guidelines on how PRs should be reviewed. This includes who should review, the timeline for reviews, and what aspects of the code should be checked.
Review Rotation: Implement a review rotation system to ensure that reviews are distributed evenly among team members, and no PR goes unreviewed due to oversight.
Foster a Culture of Quality
Emphasize the importance of code quality in your team’s culture. Reward and recognize team members who consistently perform thorough reviews. Ensure that team leads and senior developers model the behavior expected of all team members by rigorously following review protocols.
By taking these corrective and preventive actions, you can address the issue of unreviewed merged PRs effectively and create a robust system to prevent it from happening again.
Last updated
