In an article I wrote on Linkedin (I apologise if the article is in Italian), I talked about some rules I think it is good to keep in mind when reviewing a PR. They are not laws but simple suggestions on what my approach to the subject is.

Here instead I would like to talk about the tools and methods I use to review code hosted on Github.

Working in a large and structured company puts a lot of strain on the review phase. The number of open PRs, in line with the number of active projects, is quite a challenge. Keeping an eye on things, especially when you are senior and cross-interested in several projects is not easy.

So how do you make sure you don't lose sight of any information?

Email

The first step is to keep emails in order. It may sound trivial, but when you follow several repositories, the number of emails you receive is really high.

Thanks to the use of Gmail's filters and labels and the separate view by label, I have been able to dedicate areas of my mailbox to just checking code-related messages.

As you can see from the screenshot, I have two separate streams regarding the two organisations I follow the most. The first is my company repos and the second is the Italian OCA community Odoo repository. The rest of the repos, being secondary and being able to wait longer for a review, are delivered already read inside my email box so as not to generate further noise.

I use the Inbox Zero approach and this configuration helps me to arrive at the end of the week with all the PRs visited and the box empty.

Github Interface

I am not a big fan of the Github interface when it comes to PR. I find some things unclear and it is very lacking in information but in the long run, you actually get used to it quite easily.
When I have some downtime (e.g. waiting for automated tests to finish) I usually open a bookmark in which I set up a filter for the PRs I'm interested in seeing on the fly. This allows me to jump straight to those that I consider to be the most urgent and that need of my intervention as soon as possible.

This screen helps me understand the situation of active developments and how much work is accumulating as we go along.

In order to obtain only the PRs I consider important, I created a filter similar to the one below:

is:pr archived:false is:open draft:false user:YOUR_GITHUB_ORG -author:app/dependabot -label:"Don't merge"

• is:pr - is used to filter only PRs (no issues)
• archived:false and is_open and draft:false - are used to filter only active PRs
• user:YOUR_GITHUB_ORG - In our company, each PR is opened on a dedicated branch within the organisation so that anyone can always be ready to take charge of the change for the most diverse cases. In this case I am only filtering the company's PRs.
• -author:app/dependabot - all automatic dependabot PRs are excluded
• -label:"Don't merge" - We use a dedicated label to block any possible merge if there is still work to be done on PR. By doing so, we exclude all PRs with that label.

Github CLI with Dash extension

OK. Here we go. Here we finally come to my favourite instrument. Being a terminal lover, I try to get my whole life flowing in there! Github CLI, known as GH, allows me to perform a number of tasks with Github repos that I need to maintain more easily, plus it allows me to take advantage of some very interesting extensions. One of these is Dash. Thanks to Dash, I have converted the filters I also use as an interface into a much more comprehensive collection of information and, thanks to the use of the keyboard, I can easily move between PRs and perform a large number of tasks.

My collection of PRs to a dedicated tab that distinguishes it from any other collections (1)

In the central part I have all the necessary information about PRs thanks to the presence of the repo, title, author and situation on checks and changes present. This helps me focus on PRs that have already passed the various checks or smaller PRs when I have less time. (2)

With the main recap I know where the PR started and where it is about to be merged. (3)

The body of the is always clearly visible. There, often, there is useful information to know to understand some things about the development contained in the PR. (4)

Our CI/CD checks are critical to the conclusion of the PR life cycle, and having them in sight makes it easier. (5)

I can read comments left by other reviewers or see responses to comments previously made by me. (6)

Discord

A small mention should be made of the integration we have created between Discord and Github. This allows us to see the continuous flow of PRs arising and their evolution.

Conclusions

I always reiterate how critical the review phase is to successful projects and to truly quality code. Using the right tools and
processes can really make everyone's life easier.

This may not be the perfect list, and there are plenty of tools and services out there that help so much. This is just a look at what I personally use and the tools that have helped me the most over the years.

If you too use any tools that help you in this task let me know in the comments!