Inbox zero your pull requests, get to "PR Zero"

Pull requests are all about waiting: Waiting for review, waiting for a comment, waiting for the developer to click that merge button... what a waste of time!

In this post I want to share with you my team's journey from having lots of work-in-progress open PRs to PR Zero - or at least very few of them.

How we got to PR zero

Specifically, we did these three things to get there:

• Encourage smaller pull requests.
• Reach developers directly when reviews are critical.
• Celebrate progress towards PR Zero in Slack.

We used Sleuth Automations to do them consistently.

Encourage smaller pull requests

The smaller the PR, the easier and faster it is to review, and the surface area for defects is smaller. So releasing in small batches not only helps with speed but also quality of the code you ship.

In our Automations Marketplace, we have a collection of PR checks that will help you do this. They are:

• PRs cannot have large or gigantic batch sizes*
• PRs cannot have more than X changed files
• PRs cannot have more than X changed lines

* Sleuth automatically determines the batch size through an algorithm that looks at the number of files changed, number of commits, number of lines changed and so on.

My team is using the last one: the check that limits the number of changed lines.

When you install it, you can configure that number of lines. What's kind of cool is that you can configure the lines differently. So for example, I want only 100 lines added. I can also actually add a limit on deleted lines if I want to.

So what does it look like for a pull request check to fail? It puts a red block on your pull request like so:

There is a way around that by going into Sleuth and clicking Ignore on the check. You may ask, "Well, if you can ignore it, then what's the point of a pull request check?"

Actually the point of a PR check is to cause the developer to be aware of what's happening. Sometimes it's easy for you to just ship a bunch of lines of code and not really think about it. But a PR check will add that extra step. The developer has to go in, see it blocks their PR, go click ignore, and that hopefully will help them think about what they're doing.

So for example, I know this has changed my behavior personally. There's many times where I would do a pull request and it had a lot of lines of code and I didn't really think much about it. And then I went and saw that it blocked my merge and then I go, oh, you know what, you're right. I really do need to make those pull requests smaller. So I went back into the code itself and turned that into multiple pull requests.

Reach developers directly when reviews are critical

In the Automations Marketplace, there's another type of Automations called Notifications. There is a particular one we're using which notifies reviewers when reviews are requested for PRs with a specific tag.

Basically how that works is if you put, say, the "important" label on a pull request, it will notify a channel. When you're installing it, you can say what label you want and then what channel the notifications go to.

This is something that my team uses not every day, not even every week, but every now and then when there is a critical fix that we want to get out ASAP. It automates some of the tedious bits of going and bugging people manually on Slack. I just add an "important" label on my pull request and now everyone's notified.

Celebrate progress toward PR Zero in Slack

We have an Automation that sends a daily summary of all open pull requests in Slack. When you install it, you can choose for a project, you can choose when you want a report of all open pull requests sent to Slack. So at the end of the day, when people are wrapping things up, there is a message in the dev room about what open pull requests exist.

Over time, that list of open PRs for us has gotten smaller and smaller and smaller. We ship many things each day, so our list of open pull requests tended to be quite long - 10, 15, 20 perhaps, of open PRs. But because of this daily notification, it's now encouraging our team to not have things just sit around.

Your own journey to PR Zero

Pull request zero or PR zero, much like inbox zero, takes work, discipline, focus. But much like inbox Zero, the payoff can be huge: Happier developers, more business value, and faster responses to changing requirements.

We got there by using the Automations above, and you can certainly jumpstart your journey by doing the same. But don't limit yourself - browse our Automations Marketplace to find more PR checks that would work for your team, including the one that lints PR for you!