Going forward with Quality

Kent James kent at caspia.com
Tue Sep 4 17:51:26 UTC 2012

On 9/2/2012 9:17 AM, Ludovic Hirlimann wrote:
>   Going Forward
>     I Bugzilla
> We need to find a process that works for both developers and people 
> involved in QA so that bugs get fixed.
> We need to fix old bugs ...

> Here is the easy list of criteria we should use for bubbling up bugs  :
>  1. Number of people affected (we'll probably need some input from
>     support for this)
>  2. Is it because of a new feature ?
>  3. Is it a main feature of the product (eg an edge case of printing)
> Then we'll need a way to expose those bugs/ issues to devs and devs 
> will need a way to look/assign and fix these. I'm thinking about 
> sending a summary email on a know occurence (eg once a month, a week , 
> every 15 days) ?
> I think that once we've got a list of criteria that both devs and 
> contributors to quality agree , we'll just need to have more people 
> helping in bugzilla.
> Right now there are between 0 and 7 people helping at various levels 
> in bugzilla (some searching for duplicates, some moving to the proper 
> component, some asking question and trying to get more information 
> from our users, some closing bugs that we can't do much with - because 
> of lack of precise information). While I've been trying over the last 
> few years to grow the number of contributors in bugzilla - I've never 
> managed to have it grow. People come , stay and leave except a few 
> exceptions.  So if you have ideas on how we could manage to grow the 
> number of people caring with bugzilla  please chime in.

I see a number of people who seem to engage at some level with bugzilla 
and do some great work trying to narrow down issues. What I don't 
frequently see is that the work they do ever gets translated into 
developers actually taking on an issue and solving it - unless the 
problem is associated with a new feature, or is a regression. Old 
familiar bugs get no traction. I've never understood how the existing 
people who do try to manage BMO keep motivated when the result of their 
work is so often duping to an old, ignored problem.

What I've always wanted to see is some way of empowering the BMO 
managers to have some actual authority to get particular bugs addressed. 
That of course is going to be even more difficult in a volunteer-driven 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120904/a6604d01/attachment.html>

More information about the tb-planning mailing list