Bug reporting sucks, and how to fix it

Bug reporting sucks. Every time I’m forced to do it, it’s laborious and soul-draining. It makes me give up hope for free software having a viable future. But it’s necessary, (a) as the way I “pay” for free software, and (b) to see if maybe I can slightly hasten a hypothetical future where the software I rely on daily might work reasonably well (it’s coming!!).

Here are the stages of bug reporting, and why each of them sucks:

1. Tolerating the flaws in the software because it’s better than filing bugs about them (time frame: 2 weeks to a lifetime)
   This stage is probably the worst, in the most insidious way, because although it is less tedious and frustrating than the following stages, it’s the one that inspires the most hopelessness in you. Unless you are completely enshrouded in ideology, you will begin to resent your computer more than Windows users do. 
2. Figuring out against which package to file a bug (1 minute to 2 hours)
   We’re only in the second stage, and already you have to have a pretty deep familiarity with Linux and bug reporting in general to move forward. Say, for instance, that Flash is crashing Firefox. Holy hell do you have a lot of work to do! There are probably at least ten independent variables at play here, including the obvious culprits Firefox and Flash, but also your video card drivers, your Firefox plugins, and your window manager. If you don’t spend enough time experimenting with different combinations of these variables (remembering that this bug almost certainly isn’t reproducible on command), then you’ll be wasting everybody’s time by filing against the wrong package. 
3. Figuring out where the culprit package tracks its bugs (2 to 10 minutes)
   Ooh, this is fun. First go to Launchpad, naturally. You might encounter several pages that look suspiciously similar; if that happens, just close your eyes and pick one. If your package isn’t on Launchpad, you might get lucky and find a link to some Bugzilla site or the project’s home page (“I hope the devs still own that domain!”), otherwise you are at the mercy of Google. 
4. Remembering your password/creating an account at the correct bug tracker (1 second to 10 minutes)
   Oh right, there is no universal login for *all* Bugzilla sites, of course, so I’m going to have to create a new account. Oh, it says there already is an account associated with my email address. Huh. Ok, send me the link to create a new password. Did that go into my spam folder? Oh, ok, finally, here it is. Alright, click. Now to file a new bug. Oh wait, I’m not logged in? I thought that would have done it. Ok, “Log In.” Ok. 
5. Looking for an existing report concerning your bug (0 seconds to 15 minutes)
   I have seen bugs with dozens of duplicates attached to them. Developers must love that. Launchpad does a pretty ok job here, searching for existing bugs based on the title you give. It’s not often that I see a match, and when I don’t, I’m not completely confident that there isn’t one somewhere in there. I usually resort to Google and use my own human brain to figure out other ways the symptoms of the bug might have been worded. I don’t want to be one of those dunces who files duplicates, after all. 
6. Verbally articulating the symptoms of your bug in a way that is succinct, unambiguous, and thorough (2 readings of Strunk & White)
   Ok, I hope you’ve got a liberal arts degree. Oh wait, you don’t, because you are using Linux. Hell, even if you do, sometimes the subtle conditions that lead to the exposure of a bug are so difficult to describe that you end up with bloated sentences in which you’re mostly trying to convey something visual or with a far too complex linguistic parse tree:

   “So, then if I click on the button again, this time *after* clearing the .config directory, but without having restarted the program, the drop-down list (usually just the “Profiles” one, but sometimes all of them) will lose any entries that I created (except for the ones made before I upgraded to 0.0.2.11).”

   What you find yourself wanting to do is take a video of the problem occurring, but that would require subjecting yourself to the hell that is desktop video recording software for Linux, a path that will only leave you spiraling further and inescapably down into the toilet that is the bug reporting process. 

7. You’re done! Oh oops, you’re not. Collect system logs and info (2 minutes to 30 minutes)
   One of my least favorite memories in life is the hours I spent diagnosing a problem with hibernation on my laptop. Or was it hibernation and sleep? Who the hell knows, the shit didn’t work and I banged my head against a brick wall of diagnostics and bug reporting and researching so furiously that by the end of it my roommate found me naked on the cold tile floor of our bathroom, shivering and blanketed in sweat. Oh, did the bug ever get fixed? Is there a difference between a bug getting fixed and your brain coping with the stress of it by making you numb to it? I don’t know. I don’t know. Oh anyway, yeah, be sure to grab some logs and shit, they’ll probably need that. 

That’s it. Oh my god I hate it every time, it’s like pulling god damn teeth, and it’s a wonder anybody chooses to do this with their free time. What in the hell is wrong with me? And more importantly, how can we make this better? I have an idea, but I’m too emotionally exhausted right now to get into it.

Update: Part 2