Rudder fall 2018 bug crunch

Middle of Autumn is that kind of period of the year where you look back at the past month, the lovely spring, the hot summer, the crazy La Rentrée, and wonder… Why on earth are there so many bugs open in our ticketing system?

Especially so many little things, not the kind that cause serious problems – we know how to prioritize those correctly and just deal with them in the listed order. So for three days, from November 12th to 14th, the Rudder team ran a bug crunch. The goal was to clean up as many bugs as possible in that period!

Prepare your tools

Some set-up was needed, and we spent time the previous weeks asking the community what were their most ulcerating little bugs, the ones threatening them of death by 1000 paper cuts. We also spent quite some time sorting open bugs, estimating what were the “very small” ones (ie the ones that should be corrected in a couple of hours), and getting a nice list of little bugs and bugs that were most likely outdated.

We also set-up a dedicated, one-shot google sheet for interactive tracking of what was needed to be done by who (working on it, PR ready, correction on PR needed, bug rejected, etc). We prefer that to kanban-like post-its, because it’s easier to automatically link towards PR. And with a big monitor screen on it, the progression is very visible.

Ad-hoc, disposable – but efficient – task manager. Actually the green lines were filtered out so that we only had action lines

Action time!

The three days of bug crunch were very intense for the team. Seven people, analysing problems, finding solution, context switching to PR validation, understand 4 year old reports, and all that with a rapid turnaround… But the team proceeded with an extreme efficiency – it helps to know each other very well in such cases.

And the results are telling! On the evening of the third day, 134 bug tickets had been closed! More than 30% of open bugs, gone in 72 hours!

Final count down is 🌟 134 🌟closed tickets for @RudderProject 2018 bug crunch. Summary to come!

Among them, 78 are corrected tickets, and 56 are bugs that were rejected, either because they were only related to no longer supported versions of Rudder, or because they weren’t there anymore.

Creepy-crawly graveyard

Fixed bugs fall in five categories.

The first category could be labelled “better user feedback”. It contains the lion’s share of closed tickets (around 20), and covers bugs making the user wonder what’s going on in place of just using the software – typically, missing documentation, missing error feedback, badly worded description of items or logs, unnecessary information. As software developers, we know that these bugs are extremely irritating for users, but somehow they are never sufficiently striking to get the hour they need to be corrected. We wanted to clean as many as possible of such tickets – and we succeeded!

The second category is even more caricatural of “irritating, not dangerous, bugs”. We are of course talking about UI bugs, all these little things (no, not the flying kind) that made the UI not exactly perfect, but that have zero consequences on the business logic of the soft – you know, a bad color there, an ugly spinning wheel ( ⇒), some mis-aligned items… Around 10 of such little pests are gone!

The next category turns around a better integration of Rudder on Windows nodes. No more strange names for Windows kernels, no more impenetrable error message about “culture” or other localisation problem!

The fourth category deals with hardening consistency of Rudder standard techniques and generic methods. We dealt with around ten bugs linked to bad reporting or bad behavior of techniques.

Finally, the last categories cover… The last 5 bugs or so. One dealt with OpenSSL 1.1.1 support (because OpenSSL broke the 1.0 <-> 1.1.0 cert format…), a better cleaning of node resources (policies, node key) on node deletion, a better support of IPv6 component in node inventory, and a couple of other things.