Pull requests are king. Still, even royalty needs to be monitored to optimise certain processes. Project management tools do a good job keeping track of issues and their associated pull request but they are not close enough to the action. We propose a new way of monitoring pull requests to minimise their time to merge.

Pull requests are a widespread tool that developers use to propose changes to git repositories. Yesterday alone (July 15th, 2021), there were almost 120 000 pull requests opened over public repositories on GitHub.com. With all this activity, it can become hard to understand which open pull requests require attention and what is the appropriate action.

Pull requests in large repositories

Whenever a team is managing a large repository, it can become difficult to navigate the sea of open pull requests. The google/guava project, which contains Google core libraries for Java, is an example of such a large repository. Here’s what the open pull request list looks like:

Currently, GitHub provides a list of pull requests with filtering capabilities such as labels, review information, and relevant participants. However, with this view, for a particular pull request, it is not clear what is the main blocker and who could unblock it.

Pull requests in projects across multiple repositories

The second scenario is when a project is distributed over multiple git repositories. If you want to get a sense of what is happening in the pull requests on the entire project, you need to open each individual project pull request listing. As an example, for the Apache APISIX project, which involves 7 git repositories, you would need to open 7 different views individually.

Not only is this annoying, but it also misses potential dependencies between pull requests from different repositories. Suppose that you have a project composed of two microservices distributed in two different git repositories where one is a library and another is a consumer of this library. It is not uncommon for, within the same release, to have a change that requires changes in both repositories where pull requests are related to each other.

A board to rule all pull requests

To help teams structure their reviews and release processes, we have added to Reviewpad a fully automated board of pull requests that is fully integrated with GitHub, GitLab, and Bitbucket. The board represents the lifecycle of pull requests across all projects known to Reviewpad. It allows teams to easily understand and resolve bottlenecks when it comes to pull requests. By the way, by design, it requires zero configuration and it is not configurable for now. We wanted to have a board that emulates the simplest review process that could be used by teams that are starting to do code reviews, and teams that are going back to basics!

The ultimate goal of this board is to facilitate communication during short meetings, to decrease the overall time to merge. At Reviewpad, we have been using this board for our daily syncs as opposed to a board of issues with the mindset of continuous code reviews, and it has substantially reduced friction in our releases.

In this current form, the release board has a pre-determined and fixed set of seven columns, and it should be interpreted as a pipeline. For example, a pull request in the column of Missing approvals is guaranteed to have git conflicts. Similarly, a pull request that has Failing protection rules is guaranteed to already have the required approvals for merge.

Here’s the information on each card:

The information is composed of four sections:

1. General information – project, title, author, last updated time and branches involved in the pull request;
2. CI checks results;
3. Reviewers state;
4. Labels.

So far, we have found that with this information we can quickly understand the issue blocking the pull request and the person who can help unblock it.

Filter by repository, participant or label

Simplicity is key. The only filters you can apply to the board are to select repositories, participants, or labels. Here’s an example of filtering by the google/guava project.

The board becomes particularly useful when you have a project that is distributed in multiple git repositories like the example we showed above.

One trick that is particularly powerful with our board is to re-use labels between git repositories, for example for milestones or priorities.

Fully automated

A basic requirement we wanted for our board is that it must be fully automated. For instance, if a pull request is in the column for missing approvals gets the required approvals, the card that represents this pull request should automatically advance in the pipeline.

The automation is not tied to the usage of Reviewpad. In the example above, the card would automatically move forward, to the Ready to merge column, if the approval was done directly on GitHub.

Cool. How do I check this out by myself?

We have a public beta version of Reviewpad available at https://beta.reviewpad.com. You will need to create a new account and once you log in for the first time, you will see the following page to connect to a code host:

You can connect to GitHub through our OAuth app or manually add a personal access token. The OAuth requires minimal scopes to be able to read and comment on public repositories.

And that’s it – you will be able to give Reviewpad and the release board a spin on public repositories! We will be adding more and more public repositories in the upcoming days – feel free to reach us on our community Slack with requests!