Bug Hunting

Two years ago we set ourselves targets for bug reduction for a year ahead, and we did the same again a year ago. The TL/DR is that we met the target last month. Over the last two years we’ve reduced our bug count from 605 bugs (August 2017) to 404 (July 2019). This isn’t because we’ve slacked off on testing for, identifying and recording new bugs! We’ve actually stepped that up a notch. In the last two years we’ve closed 636 bugs, but we also opened 435 new ones. So the net result is we have made good inroads on bugs, rather than wiping out all the recorded bugs entirely.

The graph below tells the story. Live bugs are bugs we still have. Slain bugs are bugs that we have identified and fixed.

As you can see, the bug slaying activity has been sustained continuously over the two years, rather than being in fits and starts. The most important aspect for us is that the proportion of live bugs (blue) relative to slain bugs (green) has decreased substantially, from 55% to 23%.

Our scope for improving the proportions further is limited. Many of the live bugs are ‘hard’ because we have already dealt with most of the easy ones. Some potential future improvements we have in mind could be seen as ‘massaging the statistics’. For example, we want to take the 64 enhancement requests out of the 404 live bug counts. We have those requests for improvements in our bug tracker, but arguably they belong somewhere else.

Most of the bug tracking and recording and checking bugs really are fixed is done by Peter Sampson. He doesn’t get nearly enough outside recognition for the work he does. David Bailes reports and fixes the lions share of bugs related to accessibility, which often affect users with normal vision too. Steve Daulton is the main person finding and fixing Linux-only bugs. Other developers pitch in too, especially with clearing the more serious higher priority bugs.

The number one place we find out about new bugs from is you. A big thank you to all of you who report bugs back to us, and who help us reproduce them on our own computers, so that we can then get on the path to fixing them.