"Deal with the great while it is still small" - Tao te Ching
Dormant Pull Requests
The Mrgr dashboard has a new tab that tracks dormant pull requests. Quickly addressing items that end up on this list can drastically improve your team's velocity for the simple reason that it's easy to solve smaller problems than bigger ones. Today we'll outline the background for this important new feature.
Why does dormancy matter?
If your team is hacking on a PR, adding comments and addressing feedback, you can probably disregard that PR. Things are under control. However, if activity suddenly stops, you have the first indicators of a big problem and should intervene immediately. The risks of a quiescent pull request include:
- engineers losing context
- other PRs going in, necessitating a rebase and possible merge conflict resolution
- dependent PRs becoming blocked
- discovering a corner case or poor implementation which calls the requirements into question
The longer it sits, the worse these risks become. Every seasoned engineer has suffered the pain of stale pull requests that drag on and don't get merged. Resolving the underlying issue of a stale PR usually requires more thorough intervention, such as looping in other team members, a product manager, etc. Mrgr currently highlights the staleness of a PR by reddening the Opened timestamp on its card.
The good news is that a dormant PR is salvageable. Because it hasn't been sitting that long, it's relatively easy to revive and get merged. This is why Mrgr calls out dormant PRs - to stop problems before they start.
What makes a PR dormant?
A dormant PR is one that has had no activity in the last 24 hours. A PR may remain dormant for up to 48 hours (t+72 hours from the last moment of activity), after which it's considered stale and removed from the dormant tab. Both dormant and stale PRs show up normally on all our other tabs.
Posting a comment, pushing a commit, and leaving an approving review all count as activity; any of these will either stave off dormancy or revive a dormant pull request. Such activity is captured in the Recent Activity sparkline on our PR cards.
We do not count weekends towards the dormancy timer. A PR opened on Friday will not be considered dormant on Saturday, but rather on the following Monday, giving you and your team 24 working hours to review it, comment on it, etc. That way you won't come back to work with a bunch of needless alarms going off.
The goal of identifying dormancy is to nip staleness in the bud. By focusing on the problem while the problem is still small, it's easier to prevent it from becoming a big problem. That's why tracking and unblocking dormant PRs will significantly improve your throughput.
Bonus Feature! Additional Filtering
But wait, there's more! Custom dashboards have two new filtering options: draft status and requested reviewers.
Draft PRs are excluded from our other tabs to keep your focus on what's actively ready for review. If your team uses draft PRs to bat ideas around you can now keep an eye on that activity. Note that draft PRs do not trigger High Impact File alert emails.
Filtering PRs by reviewer is a great way to keep track of which pull requests have been assigned to you. In fact, when you create a Mrgr account we automatically create a custom tab to track PRs where your review has been requested! Fun and easy.
It's possible to build these queries into Github's PR filtering mechanism of course, but isn't it easier to use our dropdowns?
Happy merging!
