User: Password:
|
|
Subscribe / Log in / New account

Development issues part 2: Bug tracking

Development issues part 2: Bug tracking

Posted Jan 10, 2008 17:18 UTC (Thu) by iabervon (subscriber, #722)
Parent article: Development issues part 2: Bug tracking

I think one common problem with bug tracking systems is that they don't provide a good
workflow for reporters from the point of having a problem to the point of getting other people
involved. It is pretty much impossible for a user with a problem to identify whether the
problem has been reported already by using the query capabilities built into most bug
trackers, and, if a user doesn't find their bug already in the system, they have to re-enter
all of the information that they used to search with. Furthermore, the user has to do
something different to find out that something is a common user error. And the user has to do
yet another thing in the case where the problem has been reported by somebody else, but the
report doesn't cover all of the aspects of the new situation. So there's a high chance of user
error in this process, and poor handling of failure cases.

On the other side, one of the most useful things in resolving a bug is a second report which
clarifies or corrects the description of what's actually going on, and this is something that
bug tracking systems and triage actively filter out at pretty much all stages.


(Log in to post comments)

Development issues part 2: Bug tracking

Posted Jan 11, 2008 17:14 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Furthermore, the user has to do something different to find out that something is a common user error.

I think a bug tracking system (or, more generally, a bug handling process) is a horrible way to deal with common user errors. I'd rather see effort put into fixing the product design and/or user documentation than providing a way in the bug reporting process for a user to find out that what appears to be a bug really isn't.

For example, I've found that simply producing quality error messages goes a long way toward that.

Development issues part 2: Bug tracking

Posted Jan 11, 2008 21:48 UTC (Fri) by iabervon (subscriber, #722) [Link]

Well, another issue is how you deal with things that are fixed. Until everybody is using a
version of the software which has an appropriate error message, which is effectively never,
there will be people who get the old behavior and can't find out from the software that a
newer version is available and fixed their issue.

And, of course, fixing the user documentation doesn't help, because users never read
documentation until something goes wrong, at which point they're faced with the choice of
whether to go to the documentation or to the bug tracker, and they don't necessarily do the
right one. Ideally, there should be some common troubleshooting starting point where the
answer can be: read this section of the manual; or use a version newer than X; or wait for the
next release; or add your account of the issue to this bug; or make a new bug with this
information.

Development issues part 2: Bug tracking

Posted Jan 19, 2008 14:45 UTC (Sat) by fergal (guest, #602) [Link]

On the other side, one of the most useful things in resolving a bug is a second report which clarifies or corrects the description of what's actually going on, and this is something that bug tracking systems and triage actively filter out at pretty much all stages.

One way to solve this (and several other problems) is to distinguish between bugs and bug reports. I've only ever seen one bug tracker that did this (written for the linux kernel but not adopted). Bugs and bug reports are different concepts and yet all popular bug trackers mush the 2 concepts together, leading crap like "closed as duplicate" and all the pain that comes from that.

If you separate the two concepts, then users file reports, triagers either create a new bug or attach the report to an existing bug. Duplicate reports become harmless or even positive if they contain extra info. You can even attach a report to multiple bugs.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds