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

Development issues part 2: Bug tracking

Development issues part 2: Bug tracking

Posted Jan 11, 2008 17:14 UTC (Fri) by giraffedata (subscriber, #1954)
In reply to: Development issues part 2: Bug tracking by iabervon
Parent article: Development issues part 2: Bug tracking

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.


(Log in to post comments)

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.


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