Why we built GitGumbo

This is the first post on this blog, so it should probably explain what this thing is and where it came from. The short version: GitGumbo was not designed. It accreted.

It started on the command line

Long before any of this had a web page, it was a script.

The problem it solved is one a lot of teams have and nobody talks about much: merge requests go quiet. Not blocked, not rejected — just quietly un-looked-at. A review sits for four days because everyone assumed someone else had it. The information is all there in GitLab, spread across a list that sorts by the wrong things and tells you an MR was "updated 3 days ago" without telling you whether that update was a review or a typo fix.

So the first version was small, unglamorous, and ran in a terminal: pull the merge requests down, sort them by how stale they actually are, print the list. That was the entire product, and it was already useful enough to keep running every morning.

Then it sprouted wings

A terminal list is a fine answer to one question and a bad answer to the next one. We wanted the issues too. Then we wanted them in columns, because a list of issues is just a list and a board is a picture. That turned into reading each project's real GitLab board configuration and building the columns from the labels already in use, rather than making people re-describe their workflow to yet another tool.

After that it kept going, and it mostly kept going for the same reason each time: you are in GitGumbo, you want to do a thing, and doing that thing means opening GitLab in another tab. Nearly every one of those tab-switches turned into a feature. Milestones and due dates on the cards. Blocked and blocking relationships drawn as actual lines between actual cards. Creating a merge request straight from a card. Confidential issues marked as confidential instead of rendered exactly like everything else, which is the sort of thing you only notice when it nearly bites you.

Where it ended up

The honest measure of whether this worked is not a feature list. It is that we almost never open a GitLab board directly any more. GitGumbo is the tab that stays open. When we want to know what is happening, we look here first, and we look at GitLab when we need to do something GitGumbo has not learned yet — a list that is shrinking, but is not empty.

It reads GitHub too, now, which was not the original plan either.

What this blog is for

Two things. Product news, which also collects on the release notes page — that is the same feed, filtered. And the occasional longer piece about how something actually works underneath, because some of the decisions in here are more interesting than "we added a button".