Bug reporting sucks, it’s clear. How can it be better?

One idea that could alleviate a lot of the headaches of bug reporting while providing increased functionality is a desktop bug-reporting application. I won’t pretend to be familiar with any APIs that are made available by Launchpad, GNOME, Bugzilla, Trac, etc., but I have to imagine that some exist. I also won’t pretend that I’m the first to have this idea — it’s entirely possible that it’s been attempted and that those attempts have failed many times. But from where I’m sitting it seems like a near-perfect solution. Here are the benefits we’d get from a desktop bug-reporting application:

1. It can manage your bug tracker logins.
   Imagine having all your bug tracker logins stored in a little database for you on your desktop. More than that, imagine being able to register at a new bug tracker with just a few clicks using the personal information kept by the application. 
2. It can identify the bug tracker used by a given application.
   This may actually be a bit difficult. It’s possible that this could be done by having applications make this info available in some way, although that puts a burden on application developers, and I assume there is no system currently in place for something like this. It’d require some creativity. 
3. It can identify the package in the appropriate bug tracker against which to file a bug.
   Launchpad is probably the bug tracker with which I’m most familiar, and there in particular it seems to me to be plausible for a bug-reporting application to easily find the package against which a bug should be filed. How many people even know that Ubuntu’s default PDF viewer is called “Evince,” or that its default image viewer is called “Eye of GNOME,” or especially that the Eye of GNOME package is called “eog”? Imagine instead being able to choose from a list of running applications and having the bug-reporting application do the rest. 
4. It can provide better search for duplicates.
   Launchpad only presents you with possible duplicates after you’ve entered the title of your bug report. A desktop application, on the other hand, could continue to search for duplicates as you’re elaborating on the bug in your description, updating on-the-fly and presenting you with relevant excerpts from the potential duplicates’ descriptions. And if it has a high enough confidence in a match, it can ask “Are you sure?” before allowing you to submit. 
5. It can collect and upload system logs.
   Not only could a desktop application attach basic system logs and hardware info, but it could catalog which version(s) of your application’s depencenc(y/ies) you have installed, potentially saving hours of work per bug. 
6. It can open an impromptu chat with others suffering from the bug, or with package maintainers.
   By checking the online availability of other bug sufferers or package maintainers, this application could integrate with Empathy, Pidgin, or IRC to put you in contact with them, if they choose to make themselves available. 
7. It can search existing help avenues for potential solutions to your problem.
   Stack Exchange (Ask Ubuntu, Super User), Quora, Ubuntu Forums — searching all of these places takes time, and might not even occur to a large number of users. Searching these places on-the-fly as bugs are being described might prevent unnecessary bugs from being filed in the first place, or direct bug sufferers toward temporary workarounds. 
8. It can look for PPAs that contain updated packages that might fix the bug you’re reporting.
   Many times the applications in official repositories are outdated, and many times the most common bugs have been fixed in more recent releases. Given adequate safeguards, this could be invaluable for people desperate for a solution. 
9. It could integrate with the messaging menu.
   “Someone just marked one of your bookmarked bugs as ‘Affects me too.’ They are available for chat. Would you like to contact them?”
   “The bug ‘[bug description here]’ has a new comment.” 

I’m sure with my limited imagination I’ve not even scratched the surface of what a desktop bug-reporting application is capable of. What else would you like to see in one? What would some of the pitfalls be? Is this practical or impractical, and why?

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