Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote:
>> I wonder why do people keep complaining how their bug tracker of
>> choice sucks, instead of doing something about that.
>
> Lack of time, and to some degree a lack of clarity of what they
> want out of the thing. (Most people are very clear on what they
> don't want.)
Personally, I haven't worked with one which had the data organized
in what I would consider a sensible and useful way.
In my view there should be a *problem* report table, to describe the
problem from a user perspective. What the user experienced, without
any attempt to explain why. Error messages, steps to reproduce,
environments in which it's been seen, independent confirmation of
behavior, etc. This would be what you would primarily want to
search when you hit a bug.
There would be a separate table for an analysis of each contributing
*cause* of the observed behavior. Describe why it caused or
contributed to the observed behavior. There should be a list of
these which exist independently of the problem statement, so that
you can reference several causes for a problem report, and the cause
can be linked from multiple reports. Each cause should include a
separate section for user-oriented explanation of what to do when
confronted by this issue -- limitations, workarounds, alternative
approaches, documentation to read, etc. Each cause should maybe
have a "Not a bug" check-box. Through a table linking problems to
causes, not only could one easily look at all the contributing
causes for a problem report, but all the problem reports with a
given cause. In a field separate from the analysis, there could be
a summary of what the community consensus on a solution is.
Each cause should have a (possibly empty) *task* list describing
what would need to be done by the community for resolution. Tasks
would exist independently of problem statements or cause analysis
and could be shared among various causes. (Of course, this being a
relational database, one could easily find the related problem and
cause rows that a to-do addressed.)
I'm less clear on how work-flow management and resolution data would
tie in, but it seems like there's plenty to attach that to. The
muddling of problem description, cause analysis, solution design,
tasks needed for correction, and assignments to tasks has been an
insurmountable problem in the systems I've used so far (although
there are a great many I've never seen, so maybe someone has this in
what I would consider a reasonable structure). Any system which
starts with a "problem description" and "solution description" as
big text blobs and then jumps to a list of "assignments" (as one
product I have to use) is hopelessly broken from the start, IMO.
Now, possibly the problem is that other people think the above would
be horrible for them, and that there *is* no design that works for
everyone; but the above seems to me to model reality much better
than any bug-tracking system I've used so far.
And, as an aside, I think that calling an approach an anti-pattern
is too often a cheap way to avoid serious thought about an issue
which merits it, while pretending to the moral high ground. Better
to leave that aside and stick to remarks with actual meaning and
content. In other words, declaring something to be anti-pattern is,
IMO, an anti-pattern.
-Kevin