Are you struggling to keep on top of multiple pull requests across multiple Github repositories from multiple teams? This was my experience when I joined a new company and a normal workday involved reviewing several pull requests across one or more repositories that my team and I were responsible for reviewing and maintaining. Code review is a great blocker to releasing software when the code review session has gone stale and requires frequent check-ins.
As my team and other teams grew, so did the number of features, repositories, and code reviews; it became apparent that software was taking a longer time to ship, and on a rare occasion pull requests were opened for several days without review due to the difficulty of keeping on top of everything. It wasn't uncommon either for a few Dependabot pull requests to be forgotten about for several months because they just weren't visible through all the noise.
I found using a combination of GitHub dashboards, slack channels and 3rd party programs (like Trailer) for notifications was a great start; yet I still found myself routinely falling back to manually checking open pull requests several times during the day. Identifying changes was laborious and frequently there was no update since my last check. It was clear this was never going to scale, as more pull requests equals more simultaneous reviews.
Releasing software is comparatively much easier to measure than tracking the "real" time spent on code review. Stale reviews cause burnt cycles and delays releasing software because of inactivity; coordinating reviews in a timely and efficient way ensures features, enhancements, and fixes get shipped without delay and that all begins with improving visibility.
Let's build an MVP
Reviews to the rescue!
Reviews is a terminal UI dashboard to monitor requests for code review across Github repositories.
It began life as a simple script to list all open pull requests for a single repository, then several, and quickly evolved to do more as time went by.
The goal was to create a CLI dashboard that would poll Github for updates. Using configuration provided by a user, reviews would “watch” and render updates such as approval status, ability to merge, time the pull request has been opened, and more. This was the original idea for reviews; It has grown a little since then.
The technology behind Reviews was simple and minimal:
- click for cli
- rich for layout
- pygithub for using the Github API
A quick mock up of the UI looked like this for the MVP:
followed by an initial spike using the libraries listed above, the first incarnation of Reviews was born and it looked a bit naff!
The first release
At an internal hackathon a work, I pitched the project and managed to convince at least 1 other person to join me on the project.
Over 2 days we worked on making improvements and trying to produce something usable as a 0.1.0 version of Reviews. Back then it was called Dexi (after an energetic 3 year old said it sounded like a pokedex). It mostly worked, but it was slow, prone to errors, and had huge sections in the TUI that did nothing yet. I didn't see anyone else using it except for me for the foreseeable future.
The strangest thing happened next ; after a quick demo, people seemed to like the concept and a few folks asked how to install and use it.
Embarrassed by the hacked together code; I held off on open-sourcing it for a bit, but the next iteration was better. code-review-manager was created at version 0.1.1. It fixed several bugs, errors, code quality issues, and empty sections of UI. It was not perfect, I was still slightly embarrassed to share it at this early stage, but I figured 1-2 people viewing the code couldn't hurt.
Project Growth
As the star count began to increase on the repository from friends and co-workers, I made a post on Reddit to find contributors who might be interested in helping with the project. It gained a lot of attention and invaluable feedback was provided via feature requests.
Afterwards, reviews got an honourable mention in PyCoder's Weekly Issue 472
The above attention helped push reviews forward from 0.1.1 by 11 releases to the current 0.2.0 release and even managed to spawn a simple website: https://reviews-cli.dev/
Conclusion
If I waited until I was 100% happy with reviews, it still wouldn't be released today but I have been using Reviews daily as an enhancement to my original workflow and others have started using it too. I get to spend less time checking for stale reviews, and more time on active code review which has been a huge win.
Top comments (0)