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:
-
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. -
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. -
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. -
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. -
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. -
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. -
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. -
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. -
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?
Anon says:
I do agree that bug trackers suck, but I don’t think your idea makes a lot of sense:
> It can collect and upload system logs.
> It can identify the bug tracker used by a given application.
> It can identify the package in the appropriate bug tracker against which to file a bug
Ubuntu has `apport` and a lot of applications have “Report a Problem” entry in the Help menu, that should take care of bug reporting (at least for GUI applications). It also collects logs.
> It can manage your bug tracker logins.
this is already done by the browser
> It can provide better search for duplicates.
this is already done by bug trackers (or at least should), what I’d like to see is integration between bug trackers (upstream/downstream)
> It can open an impromptu chat with others suffering from the bug, or with package maintainers.
I don’t think it would be feasible, nor it would make a lot of sense
> It can search existing help avenues for potential solutions to your problem.
> It can look for PPAs that contain updated packages that might fix the bug you’re reporting.
This information should stay in the bug webpage as a reference.
What I would like to see is integration between different bug trackers and the ability to forward a bug without having to login again, copying the bug report etc. Also, merge bug comments in a meaningful way to minimize duplication of effort. If you have a bug in EOG you will probably have three different bug reports about it, one upstream, one in Ubuntu’s bug tracker and one in Debian’s. It is not unusual that each of them have different info about a fix or a patch attached, this is plain stupid.
I would push for strict DVCS integration with bug trackers.
I like launchpad because you can link a branch with the fix in the bug page, AFAIK bugzilla can’t do that.
mpt says:
I worked on the design of Launchpad’s bug tracker (along with other parts of Launchpad) from 2005 to 2007. We got some things wrong, but I think at least we improved on Bugzilla. ;-)
The purpose of a bug tracker is to improve software. It does this by helping developers make the best use of their time, giving answers to the question, “What should I do next?”.
It is easy to confuse this purpose with other possible purposes. For example, it is not the purpose of a bug tracker to act as a tech support forum. A bug report used as a support forum rapidly becomes harder and harder to use as a forge for actually fixing the bug. So, it may be interesting to put reporters in touch with other people suffering the same problem, but when designing a feature like that you would need to be careful not to encourage chit-chat in the bug report itself.
As another example, it is not the purpose of a bug tracker to make it easy to comment on bugs. Bugzilla got this wrong, with large comment fields and comment numbering and reply quoting and so on, which made it easier to chat in a bug report and therefore harder to pay attention to bug notifications or to understand what a bug report is actually about.
Most importantly, it is not necessarily the purpose of a bug tracker to make it easy to report bugs. As the number of open bug reports increases linearly, the time for triagers and engineers to deal with those reports also increases nearly linearly, but the probability that any of those bugs will be the most important thing for a developer to work on next *decreases* exponentially (because new reports are more often duplicates, or tiny edge cases, than old ones are). So, sometimes more bug reports are actually a bad thing.¹
For example, right now Ubuntu has 96180 open bug reports, of which 56241 — more than half — are “New”, i.e. Unconfirmed.So what would help Ubuntu improve most are things like better duplicate detection, more efficient triage, and possibly even *fewer* bug reports to begin with.² None of that would be helped by a GUI application for bug reporting.
That isn’t true for every project, though. A project may have few users, but an active maintainer, who is happy to give careful attention to every bug report. In that case, bug reporting should be easy, and some of the other features you describe would make sense.
One awkward thing about Launchpad’s bug tracker is that it doesn’t cater for this variety of projects. It is exactly as easy to report a bug on a project that is overflowing with bug reports, than on a project that really would like more of them .
______
¹ In a public open-source project, this isn’t the whole story. For example, a new contributor may start out by browsing the bug list, and pick a low-importance bug first because it’s easy to fix.
² For example,anyone used to be able to report a bug on Ubuntu without specifying the package first. Nowadays, you can do that only if you’re a member of a particular team, or if you know the secret URL. This is a rough way of simultaneously making bug-reporting a bit harder, and making triaging, on average, a bit faster.
Jay says:
Thanks for your feedback mpt. I always enjoy reading your take on things.
I understand what you’re saying about the risk of turning bug reports into support forums. That’s a pet peeve of mine as well, both as someone who subscribes frequently to bug activity and as someone who sympathizes with the plight of those responsible for bug reports. I understand that putting people in touch with package devs and maintainers could be a major annoyance, and I don’t think I adequately expressed my trepidation at the idea. Of course there’d have to be many safeguards. It’s not a mature idea.
I do think however that it could be valuable to have IRC channels devoted to a bug. I can imagine a scenario where two or more people who are affected by a bug would find it productive to talk about their symptoms and potentially arrive at a better diagnosis or a workaround themselves. If anything I think something like that could help alleviate the bug-report-as-forum problem. Not to mention a simultaneous search on actual support forums. Again, these ideas are not fully fleshed-out.
Launchpad is in my opinion one of the better bug trackers there is, so I appreciate your involvement there. I’m not sure I agree with you however that it shouldn’t be easy to report bugs. Surely it shouldn’t be easy to report duplicate bugs, or detail-starved ones. But provided that all bug reports are new and well-articulated, how can that be a bad thing?
A GUI wouldn’t help as much, of course, if Launchpad were the only bug tracker (or if any single bug tracker were, in fact), but it’s not. A universal interface to all varieties of bug trackers would, I think, be an enormous boon to people who would like to help out by filing bugs.
Another thing you didn’t address — something that I think is one of the most valuable parts of the idea — is that a desktop GUI can know far more about your OS than a website. It’s not uncommon that I see a conversation taking place within a bug report wherein devs are asking users for more info, info that could be more effortlessly provided through a desktop application. I remember in particular a bug I was reporting with Miro — (a) whose package is at lp.net/democracy (I remember Miro from the days when it was called “Democracy Player,” but who else does?), and (b) whose bug tracker is at pculture.org (???) — and this bug actually came down to a bug with libtorrent. Surely it would have been easier to identify that the problem was with a dependency rather than with the Miro package itself if people reporting on the bug had thought to include their version of libtorrent — but of course most don’t.
Also if you’ve never read my blog before, please excuse the cranky tone. I exaggerate.
Daniel says:
I think it’s a great idea. I like launchpad, but when I have to go to any other project and enter a report, It’s always a pain. Even cooler, this kind of app could help you keep better track of all bugs you’ve committed, not just the ones on a particular site.
Jonathan Dahan says:
Project Planning and Support Forums may work better as separate applications. See the various web applications that use getsatisfaction for community management and pivotal tracker for project planning. These are just a pair of the more popular ones, and FOSS may want to experiment with a similar model.
mpt says:
I can’t practically tell which bug report about Ubuntu gets comments most frequently. But the most-commented ones I’ve seen are controversial, not severe, and even they get a comment only every few hours. Combine that with the proportion of bug reporters who would be interested in chatting at all, and the chance that anyone else would be in a bug report’s IRC channel at the same time as you are is tiny.
I shall try again to explain why more bug reports isn’t always better. The more bug reports there are right now, the more likely the next one — no matter how well articulated —will be a duplicate that, for whatever reason, isn’t intercepted automatically. And the more likely it will be an edge case that, while unfortunate, isn’t important enough ever to come up as the thing that one of the existing developers should work on next. But the time required to triage that bug report is pretty much exactly the same as the time required to triage any other bug report. Therefore, after a point, bug reports have diminishing returns. If the number of developers and triagers (and the efficiency of the bug tracker) increases to keep pace with the number of bug reporters, this is fine. But except in the very geekiest projects, it does not.
Many Ubuntu applications already have a “Report a Problem” menu item that navigates to the correct Ubuntu package. I don’t know whether it also transmits other data (like dependency versions) appropriate to that package. Unfortunately, the menu item appears even in Ubuntu releases, not just in alphas and betas — while crashes, which could easily be tracked in a system that doesn’t require a Launchpad account or Web browser at all, are tracked *only* in alphas and betas. It is rather backwards. Also unfortunately, the menu item is AWOL from many applications, including Miro — though Miro has its own “Report a Bug” menu item going to its own bug tracker.
Anonymous says:
White text on black background against another white background? I don’t even want to look at the comments. Suggestion: Light gray instead of black background, black text.