bugzilla triage madness :-/

[Nicolas Mailhot]

Le Mar 8 avril 2008 12:32, Andrew Farris a écrit :
> 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.

That's false. Stop thinking it. Anyone who makes the effort to go
through bugzilla (do you think developers are the only ones to hate
it) is not lacking interest. In the bug reporting workflow the bug
reporter is the one who is requested to make the first step.

Bug reporters have no way to know if lack of handling (repeated
requests to re-test, add info, or move to another  without any visible
activity development-side are assimilated to lack of handling) is due
to a bad report or lack of interest. They can *not* assume a better
report will get processed faster (all too often it's not the case). So
they cut their losses and go somewhere else after a while.

You can build trust and get people to progressively invest more time
in better reports, but that requires handling bad and incomplete
reports first, and accept that even then there will be drop-outs. You
can only start to filter aggressively bugs for components where the
trust already exists, because there is a highly-visible team fixing
problems (like for the kernel)

-- 
Nicolas Mailhot