I just realized, before I know it, we’ll be hitting 20 years of Review Board.
Man, do I feel old.
It’s hard to imagine it now, but code review wasn’t really a thing when we built Review Board back in 2006. There were a couple expensive enterprise tools, but GitHub? Pull requests? They didn’t exist yet.
This meant we had to solve a lot of problems that didn’t have readily-made or readily-understood solutions, like:
🤔 What should a review even *be*? What’s involved in the review process, and what tools do you give the user?
We came up with tools like:
- Resolvable Issue Tracking (a To Do list of what needs to be done in a change)
- Comments spanning 1 or more lines of diffs
- Image file attachment review
- Previews of commented areas appearing above the comments.
Amongst others.
🤔 How should you discuss in a review? Message board style, with one box per reply? Everything embedded in top-level reviews? Comments scattered in a diff?
We decided on a box per review, and replies embedded within it, keeping discussion about a topic all in one place.
Explicitly not buried in a diff, because in complex projects, you also may be reviewing images, documents, or other files. Those comments are important, so we decided they should all live, threaded, under a review.
A lot of tools went the “scatter in a diff” route, and while that was standard for a while, it never sat right with me. For anything complex, it was a mess. I think we got this one right.
🤔 How do you let users keep track of what needs to be reviewed?
We came up with our Dashboard, which shows a sortable, filterable, customizable view of all review requests you may be interested in. This gave a bird’s-eye view across any number of source code repositories, teams, and projects.
Many tools didn’t go this route. You were limited to seeing review requests/pull requests on that repository, and that’s it. For larger organizations, this just wasn’t good enough.
🤔 How do you give organizations control over their processes? A policy editor? APIs? Fork the code?
We settled on:
- A Python extension framework. This was capable of letting developers craft new policy, collect custom information during the review process, and even build whole new review UIs for files.
- A full-blown REST API, which is quite capable.
- Eventually, features like WebHooks, once those became a thing.
Our goal was to avoid people ever having to fork. But also, we kept Review Board MIT-licensed, so people were sure to have the control they needed.
—
I could probably go on for a while. A lot of these eventually worked their way into other code review tools on the market, and are standard now, but many started off as a lot of long nights doodling on a whiteboard and in notebooks.
We’ve had the opportunity to work for years with household names that young me would have never imagined. If you’ve been on the Internet at all in the past decade, you’ve regularly interacted with at least one thing built in Review Board.
But the passage of time and the changes in the development world make it hard these days. We’re an older tool now, and people like shiny new things. That’s okay. We’re still building some innovative shiny things. More on some of those soon 😉
This is a longer post than I planned for, but this stuff’s on my mind a lot lately.
I’ve largely been quiet lately about development, but I’m trying to change that. Develop in the open, as they say. Expect a barrage of behind-the-scenes posts coming soon.