Chris's Wiki :: blog/tech/BugReportsExhausting

Making bug reports is exhausting, frustrating, and stressful

October 5, 2014

I've danced around this subject before when I've written about bug reports (and making bug reports), but I want to come out and say it explicitly: far too often, making bug reports is an exhausting experience that is frequently frustrating and stressful.

This is not because the tools for doing it are terrible, although that doesn't help. It is because the very frequent result of trying to make a bug report is having to deal with people who don't believe you, who don't take you seriously, and who often don't read, consider, and investigate what you wrote. Some of the time it involves arguing with people who disagree with you, people who feel that what you are reporting is in fact not a bug or at best a trivial issue. The crowning frustration on top of all of these experiences is that after all of your effort and the stress of arguing with people, the bug will often not be fixed in any useful fashion. By the way, that 'deal with' is often actually 'argue with' (which is about as much fun as you'd expect).

(A contributing factor to the stress is often that you really need a fix or a workaround for the bug.)

Whether or not they can articulate it, everyone who's made enough bug reports knows this in their gut. In my opinion it's a fairly big reason why a lot of people burn out on making bug reports and stop doing it; it's not that they're making carefully considered cost/benefit calculations (no matter what I've written before about this), it's that they have absolutely no desire to put themselves through the whole exercise again. The frequently low cost/benefit ratio is a post-facto rationalization that people would reach for much less if the whole experience was actually a pleasant one.

There is a really important corollary for this: if you're tempted to urge someone to make a bug report, especially a bug report that you reasonably expect may be rejected, you should understand that you're trying to get them to put themselves through an unpleasant experience.

(I think this is a big part of why I have a very strong urge to bite the heads off of people who respond to me to suggest that I should file bug reports.)

Comments on this page:

From 62.195.238.236 at 2014-10-05 05:21:15:

having support contracts sure helps when filing bugs. If someone treats you the way you describe while being a paying customer, you can bet there will be repercussions on an upper level (let the managers talk to each other).

If, on the other hand, you use something free without support, well, one could say that you get what you paid for.

You can buy support for NetworkManager on centos, by the way. Just call Red Hat and they will accommodate you.

By Albert at 2014-10-05 05:58:33:

I fully agree.

The fact that a product is free or that one has no paid support contract is not an excuse for bullying bug reporters (not to mention that a lot of free software projects do not even offer paid support options).

By bitprophet at 2014-10-05 13:29:16:

The flip side of this (at least with regards to FOSS - commercial[ish] projects are less excused) is that for every 1 Chris Siebenmann reporting a bug in an articulate, clear, detailed manner (after having read the FAQ and having tried a number of basic troubleshooting steps)...there's 10 (sometimes 100) other bug reports which fit none of that description and are a huge sap on any maintainer's time.

That's not even going into how many (most?) OSS projects probably have a user count far outstripping their ability to find volunteers with the required knowledge, patience etc to perform good triage, let alone followup. (In other words, even if all users submitted valuable feedback, there'd not be enough hands to triage it.)

In my experience this leads to a situation which is incredibly sub-optimal for both sides (including burnout for maintainers and, as you've evidenced, terminal frustration for users) with no clear solution. To me it feels like an inevitable consequence of OSS being purely volunteer-driven, and uneven distribution of talent/experience/other qualities making for good maintainers and/or users.

By bitprophet at 2014-10-05 13:35:49:

As a followup, I'd like to note that (again as a longtime maintainer myself) there is still zero excuse for actual unpleasantness and/or "bullying" on the part of maintainers. It takes just as much energy (or less) to be firm, polite and brief, than it does to be nasty or condescending.

Speaking personally, I always respond to good-faith input in kind, and when users are being rude, I either take the high road or simply ignore them (and then make subtweets on Twitter...)

Side note, it's baffling sometimes how many first-time bug reporters act entitled and snarky ("I can't believe this bug is a problem! Why isn't it fixed yet? SIGH"), but presumably Chris and the other commenters thus far are not in that category :)

By cks at 2014-10-05 14:24:22:

First off, I may have given the wrong impression here. When I've made bug reports, I very rarely encounter people who are actively rude or abrupt. But people handling bug reports don't have to be rude or abrupt in order to create the experience I've had here; all they have to do is not really read the bug report or not really believe it. Then as the reporter you get to persuade them that yes, you really saw this and yes, it really is a real problem, and so on and so forth.

(I've wound up with the cynical belief that the more carefully you do your initial research and the more detailed information you put in your bug report, the more likely this is to happen. You can write a bug report with a careful explanation of code paths that cause issues to happen and people will respond in ways that demonstrate that they have not read it and checked what you wrote.)

Second, my experience is that commercial support is no different from OSS in this regard. If anything, my experiences with commercial support have been worse than with OSS. Certainly I'm much more likely to have to argue my way through N levels of people who do not believe me with commercial support than I am with OSS (commercial support even has a name for these people, 'first level support'). And all of my spectacularly bad bug report experiences have been with commercial support, eg this one.

(Since commercial support costs some company actual money, I believe that it's generally always going to be this way. The company providing support has a direct motive for doing it relatively badly, with first level support people who are cheap and therefore only capable of handling simple and obvious problems and who are generally encouraged to close support cases as fast as possible.)

By bitprophet at 2014-10-05 15:23:30:

people handling bug reports don't have to be rude or abrupt in order to create the experience I've had here; all they have to do is not really read the bug report or not really believe it.

That's understandable, and I'm sad to say I've done my fair share of doubting in cases where I ended up being wrong. I feel it's the same root problem I mentioned, though - most such bug reports are incorrect/mistaken/effectively spam, because many users do not think to search the tracker, read the FAQ or documentation, etc :( Maintainers are thus taught over time to assume the worst.

This isn't fair, though again speaking for myself, if a bug report is clearly articulate and provides more than basic details I'm more likely to assume competence on the part of the submitter, and thus to doubt my initial hunch that "this looks like common problem X" or whatnot. (Which is kind of the inverse of your cynical belief, but again I speak only for myself and not others.)

By Aristotle Pagaltzis at 2014-10-05 18:54:31:

It seems maybe apropos to point to The Basic Unit of Bug Report Frustration here…

By Dennis New at 2014-10-06 08:21:02:

How about adding a bitcoin tip/bounty with a bug report, or a bounty pool feature into bugzillas?

Written on 05 October 2014.

«	Why people are almost never going to be reporting bugs upstream

Why it's sensible for large writes to pipes to block