bugzilla triage madness :-/
Andrew Farris
lordmorgul at gmail.com
Tue Apr 8 10:32:11 UTC 2008
Nicolas Mailhot wrote:
> In conclusion, the open source bug reporting community is very happy
> to help projects better their software. However, the people that
> produce problem reports are very much inundated with issues that
> should be reported. What does this mean to you, the bug handlers? That
> we'd like for you to understand that every problem is not going to be
> reported in a perfect way, and simply asking reporters to work more on
> reports is not a guarantee that they will do it. In fact most of them
> will just report their activity to channels where the bar is set
> lower, and the cost/benefits ratio is better for them. The only reward
> for reporting issues is having them handled. When handling is poor
> this ratio gets very bad quickly.
This is sadly true, but its also one of the things that most pointedly indicates
lack of real interest in seeing the issues solved by the bug reporter. Often
people who report bugs in OSS communities are simply trying to get their own
favorite quirky bugs polished because they use that software... little annoying
bugs in their email client, browser, file manager. The many pieces of software
that do not get solid attention (few bug reports) still have lots of bugs, and
often get ignored by these bug reporters. They complain when small bugs don't
get attention, or get upset and stop reporting bugs.
Those reporters who decide its simply not worth a little bit of effort to supply
good background info to a bug report.. and are unwilling to retest those bugs
are 'fair weather testers'. They are generally just using the latest product
because they want the new features but really are not spending time to 'test'.
They want the bling without the effort (the definition of 'user'). Testing
software requires taking time to do things the 'wrong' way and see what happens,
to use hidden features or odd workflows, try each new feature, etc. Testing
requires *repetition* including coming back to see if the bug still exists
across releases.
Lots of people report the little things that annoy them, and have no interest in
taking extra time to follow up on the bug, making sure no regressions occur in
later updates, checking whether it gets fixed in every major code change
upstream. Those are the testers who will cry wolf and run off to report bugs
somewhere else with the lower level of effort required. They are also the least
effective at making a real impact on the code quality of the projects they are
trying to 'help'.
A tester certainly has to filter out what they want to report. There are
numerous little things that can be reported in any project, but the time just
isn't available. However, any bugs a tester does report should be as thorough
as possible, with that extra time given to providing all the information the
tester has, and responding to requests for more. You get bugs fixed that way
rather than just getting bugs reported.
I'm not saying that all the old bugs which were stale were badly reported; lots
of them were well done I'm sure. What I am saying is, a bug reporter needs to
realize that a poorly reported bug costs everyone extra time, on both the
reporter and the developer side. The reporter needs to realize that a certain
level of effort is needed to make an impact, and just going somewhere else where
its easier really doesn't solve anything. They need to realize if they have no
interest in the followup effort, they probably shouldn't be reporting the issue.
--
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29
More information about the fedora-devel-list
mailing list