Re: the bug team and gnome2.2 [many responses in one email]

[Luis Villa <louie ximian com>]

This is a very long, concatenated response to many people. Most
important bits:

*there are now many (though certainly not a complete) group of qa-maint
aliases. Anyone who wishes to join those, please let me know :)

*volunteers to help write up a bit of the website stuff would be greatly
appreciated.

The rest (also important):

On Tue, 2002-08-27 at 22:33, John Fleck wrote:
> Let me suggest that "be a team" may require a name, a slightly more
> formal organization (which is in a sense what you're suggesting below)
> and, most importantly, pep rallies and matching T-shirts (or at least
> socks with nice logos).

'Bug Squad.' :) And yes, more formal organization is definitely
something I want to have- but I can't do it without the help and advice
of the people who are hypothetically being organized :) 

FWIW, I've asked tuomas and jimmac to come up with a logo :) So maybe
tshirts aren't so far away ;) 

> This is the approach the GDP uses - a docs person with responsibility
> for user docs in each package that needs/contains user docs. It's been
> relatively successful.

Yup. That's exactly what I wanted to model this after. See my
later-in-this-email response to telsa.

> One thing that has been useful in my experience is the use of maint- and
> QA-aliases, simply because bugzilla spam in mailbox is a good way to
> ensure that bugs get a quick look (I still look at all gnome-utils out
> of habit, and can frequently quickly close 'em, just because I am still
> on the gnome-utils-maint alias). (Bugzilla is what finally forced me to
> switch to Evolution, just to manage the mail flow - good work, Luis!)
> Are we already using this to its fullest potential?

We're hardly using aliases at all at the moment. As a step in that
direction, I've just created qa-maint aliases for basically all of the
products I qa. If people here want to volunteer to help out on any of
those, please let me know. [I'll probably send out a separate call for
volunteers later.]

On Tue, 2002-08-27 at 22:53, John Fleck wrote:
> > > *triaged keyword needs to stop meaning 'luis looked at and triaged it'
> > > and start meaning 'members of the QA team looked at it and triaged
> > > it.' How do we do that sanely, so that we aren't duplicating each
> > > other's work all the time? Also, we have to do this while maintaining
> > > consistency- how is that going to work?
> > 
> > That's a difficult one. Dunno for the moment. Need to think about it.
> 
> Yeah, this is a tough one for me too. But I think having a QA maintainer
> for each package would help this a lot - split things up so it's clear
> who's responsible for what triage, rather than Luis being responsible
> for everything.

Yeah. It still needs to happen in some way, though. This is really what
'unconfirmed' is /supposed/ to mean but it is very hard to make it work
that way now.

On Wed, 2002-08-28 at 08:27, John Fleck wrote:
> On Wed, 2002-08-28 at 03:45, Vincent Untz wrote:
> > 
> > In fact, I just wanted to say that if a maintainer don't use bugzilla
> > and there is no QA guy for the package, then, maybe, the maintainer and
> > the bug team should wonder if that package needs to be in bugzilla.
> > 
> 
> No, I think it has to be in bugzilla, and our job is to figure out a way
> to make bugzilla used and useful.
> 
Absolutely, 100% agreed.

On Wed, 2002-08-28 at 07:28, hobbit aloss ukuu org uk wrote:
> I think two things made us a 'team':
> 
> * The growth of the IRC channel to a stage where there was always
> someone else on and active. I well remember the day when someone
> said "hey look! /names #docs is in double figures!" and there was
> great excitement :) These days there are regularly twenty people
> on (not that I'm there often).

#bugs should be the same way- it has tended to be bug-day centric, but
there is no reason there shouldn't be bug discussion there every day of
the week.

> * The doctable. This was (is) a webpage with a whacking great
> table on it of every package in what we considered to be GNOME,
> every application within it, and the stage the docs were at.
> There was a cycle they were supposed to go through. Like Bugzilla,
> actually. Docs became assigned, in progress, written, proof-read,
> linked in, and done. And then, often, "needs updates" :) 

This definitely needs to be done. I'd like it to have some statistics
straight out of bugzilla, too- like 'percent unconfirmed', 'percent
marked triaged', etc.

> I also think templates of "how a doc is laid out" and a GDP
> guide including that and "if you meet this, then.." and how to
> get the tools working and just about everything anyone met
> more than once helped a lot.

These types of things definitely need to get written/refined for bug
team. All that knowledge is almost exclusively in my head, so that falls
to me :/ [Andrew discusses this a bit in his email, so see below for
more.]

> The doctable went into action as the releases of gnome-core and
> gnome-applets 1.1 were being made. And yes, I do think more
> people got involved. Actually, that's a third thing: having a
> goal and a date. "Get stuff done" is easy to put off. "Get
> stuff done by..." is not. 

Good point, though bugs are moreso an ongoing project than docs are, so
setting dates are harder.

> Telsa (have I really not closed 200 bugs? How crap.)

Not in the past 8 months :) 

On Wed, 2002-08-28 at 14:05, Andrew Sobala wrote:
> On Tue, 2002-08-27 at 22:10, Luis Villa wrote:
> > *just as each package has a maintainer, each package should have a QA
> > person, or a QA team, much like nautilus (at least theoretically) has
> > ATM. Yaneti is the Galeon Guy, Kjartan is the GNOME1.4 core guy... we
> > need more guys (and gals!) who can identify with and claim their own QA
> > apps and build a relationship with the code maintainers.
> 
> And the QA guys should have written down what they have to do:
> 
> * Reproduce bugs for maintainers
> * Duplicate removal
> * Followup/close bugs marked NEEDINFO

Definitely.

> Plus others?

Yeah, probably- at some point, volunteers have to start saying
'important, not important.' Probably that'll always be up to a fairly
small group, though.

> What about libraries? Problems there are sometimes pretty hard to
> reproduce, even for part-time hackers.

They luckily don't get many bugs filed against them. I've basically
ignored them completely during the 2.0 stuff, dealing with them only
when an application revealed a bug, and that has worked out well.

> > *triaged keyword needs to stop meaning 'luis looked at and triaged it'
> > and start meaning 'members of the QA team looked at it and triaged it.'
> > How do we do that sanely, so that we aren't duplicating each other's
> > work all the time? Also, we have to do this while maintaining
> > consistency- how is that going to work?
> 
> Is a "qa-triaged" keyword, and strict instructions about who is allowed
> to use it, good enough?

Possibly. Hard to say without going ahead and doing it.

> * At the moment, Luis decides which bugs are "showstoppers" for a
> release and when other bugs should be targeted for. Without Luis, no-one
> will be doing this...
> 
> Maybe the QA people, and/or (possibly in conjunction with) the
> maintainers, need to be able to suggest (not dictate) which bugs need to
> be fixed *now*. Maybe not :)

They do. Again, we need standards for how. It's at least partially art-
so part of it is just a matter of communally discussing things.

> * A "Bugtable", like the Doctable, would be useful. Useful things to
> include are:
> 
> -- QA contacts and if they are on holiday :)
> -- No. of bugs without "qa-triaged" (or equivalent) set.
> -- No. of "important" bugs (implementation depends on point above about
> targeting bug-fix-times).

Yup. You volunteering to write a mock up in HTML, Andrew? :) 

Finito-
Luis