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