Braden McDaniel wrote:
<snip>
> Shoot the messenger, why don't you?
>
> Asa, I really don't think I could have labelled my posting as sarcasm any
> more clearly. Do you *really* think that people who want to subvert and
> abuse the system need me to tell them how to do it? C'mon.
>
> Don't try to make me the scapegoat here. There is a problem with the
> system: it is configured such that issues are "rewarded" for being
> duplicated. That reward inevitably comes at the expense of other issues.
> What I'm proposing would be a leveller. I don't know if it would cut down
> on the number of duplicate reports; but it stops specifically rewarding
> them, and that couldn't hurt.
Sorry I missed the sarcasm. I don't see the reward as clearly as you do.
The most frequent list was not set up to somehow raise the priority of
the bugs that end up there (and I doubt that it does or bugs would move
from that list a lot faster). The most frequent list was set up to help
naive bug reporters avoid filing the duplicate in the first place.
People who want to abuse the system will find ways to do that. They will
find those means more often and faster with you drawing the map for them.
But I'm more concerned about the naive than the malicious and you're
misinforming them. Bugs do not get fixed faster because "no one wants
Bugzilla to get clogged with a bunch of duplicate bug reports". If
anything, this slows the fixing process down. Those same people who
waste hours a day resolving duplicates and verifying fixes against
duplicates are the folks that could be making tests and performing
systematic functional testing on the product. In my experience a
regression (and most of the bugs ammassing duplicates are regressions)
is fixed much faster if it is caught right after it happens. If we're
too busy trying to keep Bugzilla from getting "clogged with a bunch of
duplicate bug reports" then we don't have as much time to be proactive
in our QA process and catch those problems as soon as they arise or
help development track the problem down by creating simplified test
cases. I feel totally confident saying that bugs will get fixed faster
when QA has the time to be proactive instead of reactive.
A vote is useful, and the information that a bug is high profile is
useful. But neither of those pieces of information are as useful as
a capapable person actually working to identify the root of the problem
quickly and provide a developer with clear and helpful information.
--Asa
