Off the Beat: Bruce Byfield's Blog

"Any chance of a bug report?" a developer asked when I mentioned a problem with an application on social media. As a free software supporter, I felt an obligation to oblige, but in practice, the chance was slim. For those of us who don't regularly file bugs, the process is usually too demanding, and too dependent on bureaucratic whim to seem worth the effort.

In theory, of course, I should be all in favor of reporting a bug. After all, free software depends on the efforts of responsible volunteers. Using free software regularly, surely I have a duty to get involved and to help improve the software for everyone.

However, in my case, that's not my first obligation. I wouldn't spend my time writing about free software if I didn't believe in its importance, but my first obligation is to turn in suitable copy on time. I want to write about a bug before I report it, so that the problem is fresh in my mind. By the time I'm finished, I have already spent several hours on the topic, so I am not exactly eager to spend even more time on the topic. As a writer, I am more a fellow-traveler than a loyal supporter – my priorities are similar, but not always identical.

Yet even if I can spare the time to enter a bug, I have to be strongly motivated. Every bug-tracking system that I have ever seen is designed far more for the needs of developers than for those who want to report a bug.

To start with, in many cases, you have to set up an account if you are reporting for the first time. No doubt this requirement helps to eliminate trolls, but my reaction to it is likely to be the same as when a link takes me to a site that requires registration before I can read – I am very likely to decide that I can live without the link or reporting the bug after all.

Making the report
Yet even if I create an account and continue, logging in to the tracking system is only the first obstacle. For instance, I may be asked which component of the software the bug affects, to which my only honest may be, "How would I know?" Many of the choices offered in the combo box mean nothing to me, and only a little more if they are annotated.

Nor is it always clear which component a bug falls under. Will the bug be disallowed if I choose the wrong one? What if the bug seems to fall under more than one component?

Moving on, I probably have to stop and open the application to find exactly which version of the software I am reporting on. I don't keep version numbers in my head, except occasionally by accident. The same is true of hardware.

As for Severity, how should I know? It may be critical to me, but how am I supposed to judge how the developers will evaluate it? If I set it too high, they might be dismissive, while if I set it too low, they may ignore it. Usually, I end up somewhere in the middle, which most of the time tells exactly nothing about the severity.

By the time I get around to describing the problem, I am starting to feel peevish. But then I have to muster my thoughts and figure what might be relevant to trying to fix the problem. Typically, I will need couple of hundred words to describe when the bug happens, how I have tried to solve it, and any work-arounds that I have devised. I am being asked for a mini-article, and while the actual writing doesn't take long for me, I do have to spend time on the hard part – that is, how to structure it.

Possibly, too, I may need to attach a file to illustrate the problem. Unless I want to pass along my work to the developers, that may mean creating a sample that shows the problem without violating my privacy.

By the time I submit the bug, I could easily have spent 30-60 minutes describing it. It's not a chunk of time I am likely to devote to a task on a whim, especially when the task, no matter how necessary, is tedious and confusing in small ways.

The Bug Bureaucracy
Occasionally, optimism breaks out, and I do file bugs, despite my distaste for the process. Yet the aftermath is no more attractive than the response.

Much of the problem is that I am an amateur at bug-reporting, but I am dealing with those who regularly handle bugs. I am likely to be excluded from much of the discussion, or, even worse, addressed so condescendingly that I get the feeling that, if we were talking, the experts would be speaking slowly and exaggeratedly and making broad gestures with their hands to ensure that I would understand.

Even worse, those who deal regularly with bugs have a tendency to be bureaucratic. Just as the police can be more interested in closing a case than seeing justice done, I often have the impression that classifying or closing a bug is a higher priority than fixing it. Once I give enough answers to classify the bug, nothing more is likely to happen. If I have made a mistake in reporting the bug, it is sometimes rejected out of hand.

In one case, I was told that a massive bug should be divided into at least a dozen smaller bugs, even though all the instances I mentioned were all related, and pointed to an underlying problem that might easily be missed if not treated as a whole. I was left with a choice of spending several hours filing bugs with no guarantee that doing so would do any good, or else accepting that nothing would be done, and resigning myself to finding work-arounds on my own.

In the end, I decided that discovering the work-arounds would be a better use of my time. As usually happens when I file a bug, I concluded that the exercise was too futile to be worth attempting.

In vs. out
Such incidents explain why, these days, I prefer to write about bugs and how to avoid them instead of filing a bug report. That way, I not only get paid for my effort, but I can help others, too.

Some developers would say that by not filing reports, I am avoiding my obligations as a free software user. However, what they fail to understand is that, no matter how useful for developers, bug-reporting in general could hardly be less user-friendly if it was designed that way. Unless you report bugs regularly, and are willing to spend a good deal of time advocating for your bugs, your chances of succeeding in getting a bug fixed are slim to remote.

The truth is, bug-tracking systems are a tool for insiders. For outsiders, they are a form of hostile bureaucracy that discourages their participation in endless numbers of ways. Alternatives do exist, such as Deb Nicholson's SpinachCon, that put developers and end-users into direct contact, but I sometimes wonder if the purpose of bug-reports is not to fix errors so much as to make clear who is part of a project and who is not.