Bugs are Not Issues
This is the lighting talk I would have tried to fit into 5 minutes at UDS; but because I’ll be going to the Libre Graphics Meeting in Montreal instead; I thought it better to post the talk on my blog and get you all interested in the subject.
We’re after the release of Ubuntu 11.04. What to think about the many, many bugs we’ve fixed…
Bugs are breaks in the intended function of the software.
Bug reports are little packets of information for developers, they help point out where their software is broken.
Bug discussions are comments after the report which contain a dialogue between the developers trying to fix the issue and the people who can test it and provide more information.
So what do you do if you have a problem, but you’re not sure if it’s a bug? Perhaps the system was always intended to work like that?
What we need in these instance are Issue Reports, these are little packets of information which describe in user context what the issues the user is having. They can result into either support requests, blueprints or bug reports. they’re a proto-step to many divergent paths for getting stuff done.
How do we deal with issue reports in launchpad? At the moment we mash issue reports into bug reports with special tags. We also spray them into answers, askubuntu, irc, mailing-lists and brainstorm randomly based on what the reporter knows and what the reporter weighs up on the issue.
So how would I see a user centric addition fitting into our existing Launchpad ecosystem? Basically like this:
What are your thoughts? Do you like the ideas and do you think they would improve flow of relevant information?
Tags: bug reporting, bugs, issues, launchpad, reports, Ubuntu
Martin,
This is a beautiful summary of my thoughts on “bugs”. I was in consulting for years and we stressed that everything started as an “issue”, not a “bug”. We would only acknowledge something as a “bug” once the “issue”/”problem” had been discussed. This was often criticized as “PC’ing” the term bug until people understood the real difference.
Everything starts as an issue.
Issues can then become many things: bugs, feature requests, work arounds, clarifications, documentation, etc.
Each of those had a different owner in the team. That made it so much more important to not start out declaring something as a bug.
I don’t think we’ll ever do away with the term “bug”, but I think managing perception is important so people understand that when they are filing a “bug” they may ultimately not find the answer as a patch, but as something potentially as annoying as “RTFM” (phrased in the most polite way, of course).
I like the idea. Especially for new users this would be a major improvement as one might get intimidated by the complexity of filing a bug and the question if it is a bug.
The user has a problem, he doesn’t really care about the underlaying structure most of the time, he just wants to report the problem he is facing, no matter what it is.
This extra bit of abstraction would be a major step forward in my opinion.
Makes sense.
The path from Issue over Brainstorm to Blueprint would be the hardest to get working and will likely always suffer from the separation between the sites.
One could hope that at least some feedback from those doing support could flow to the Dev context, for reducing the need for support in future iterations
Everything is an Issue. No matter if it’s a feature request, support problem, complaint, or actual functional problem in the software. Even if it’s not something in the software itself, but say a problem with the packaging of DVD media or something with physical marketing materials. They are all Issues.
And they should all be tracked in the same place. But there are many problems with issue/bug trackers that people avoid by creating other systems that are ‘designed’ for support requests, or moderated discussion. This is where askubuntu.com and forums come in. They are just workarounds to the real problems.
The thing about humans is that they are great at figuring out workarounds. And they tend toward that route, rather than fixing the real problems.
I totally agree. This gets at something I’ve been grousing about for years. I think if we differentiated between ‘issues’ and ‘bugs’ it would solve many, many problems:
* Developers would not feel overwhelmed, when the majority of their “bugs” are really just “issues”. They could focus on the subset that actually matter and are actionable.
* Users aren’t given false expectations of a fix if their issue has not made it to bug status
* Bug heat, affects-me-too, dupes, me-too comments, and so on are all simplified – they’re just permutations of issues, as opposed to aspects of bug reports.
As a user, it would be useful to build a list of “issues affecting my computer”, each associated with one or more bug reports, and as fixes become available they’re flagged, giving you awareness that upgrading or installing a ppa or backported package might give you a solution.
Similarly, if “issues” can be attached to hardware profiles, it potentially could make the inverse operation easier – upload your hardware and see issues posted by other people with your same hardware.
@Dobey – Have you talked to Tim about his Toxic Workarounds talk? Similar ideas there.
Yes, I was there. I think askubuntu.com solves that, though. The problem with forums is that bad info gets left around, and it looks like good info. But on askubuntu, comments/answers get voted up or down, so users only ever have to see the good responses.
I think this is also a large problem of why develoeprs hate bugs. They often end up with a lot of pointless ‘me too’ and other spammy comments, and none of the bug tracking systems really have any form of moderation.
As a developer, what I really care about is getting the necessary info to fix a problem or implement a feature, and the tasks associated with it. But often there is a lot of extraneous garbage in the way to deal with. There’s also a lot of extraneous junk to deal with as a user trying to report a problem, as well. The UX is just pretty horrible on both ends of the bar.
I file bugs describing my issues with software, and most get marked WONTFIX because they’re not in scope or the current software isn’t designed to work that way. That makes sense for bug triage, but not for tracking whether the software is doing what users want.
@Mr. Dawes, in classic software development a program/product manager would be going through all the spam and extraneous garbage, freeing developers to work on open bugs.
Forums are an untracked waste of time.
That is great idea. In order to use something like this Launchpad should be changed. What I really miss in Launchpad is integration of Brainstorm and AskUbuntu into Launchpad. Then tagging an issue as bug, idea (brainstorm) and question (askubuntu). Moving between this sub-systems should be simple and elegant. Like having a tabs in Launchpad.
One question this raises is – is there an official channel for feedback to Ubuntu?
Where can people go to give constructive feedback about Unity gripes and be heard by the Ubuntu developers?
@Wayne There are several official channels. Ayatana mailing list and bug reports on Launchpad against Unity would be the best places probably.
@skierpage This isn’t about “classic software development” though. This is a problem for all of FOSS. And having everything go through a program/product manager is a bottleneck.