Re: Bugtable: Feedback required

[Luis Villa <louie ximian com>]

On Thu, 2002-08-29 at 19:48, Andrew Sobala wrote:
> > Total # 'open' bugs (maybe including needinfo?)
> 
> By the "Total" field I was actually thinking "Open." Maybe it needs
> renaming.

Six of one, half dozen the other, probably.

> > % NEEDINFO [maybe 'and more than one month old'?]
> > % UNCONFIRMED
> > % not triaged
> > 
> > maybes-
> > % without a valid version number? [if we can figure out a robust
> > algorithm for this]
> 
> Maybe we should have a "Bugtable" with summary stats and really common
> links, and also a link to a CGI script that generates links useful for
> the QA team for each product.

Sounds like a reasonable distinction. My main concern is that there be a
table where at a glance, you can see

*what products do not have a QA volunteer
*what products have a QA volunteer who isn't terribly active ATM

so that new volunteers can have a useful spot found for them and team
leaders can figure out if older volunteers need to be poked.

>  I can see that there could be 10-15
> "useful" links:
> 
> -> Needs versioning
> -> Needs qa-triaging
> -> Unconfirmed
> -> Old NEEDINFO (an argument against: bugs are too precious to do a mass
> close, especially if a bug has a stack trace)

No, it's useful. If a NEEDINFO has useful information, then it doesn't
'need info'. A bug should generally be NEEDINFOd only when no further
progress can be made towards solving anything without more information.
So... yes, old NEEDINFO is legitimate- those should be periodically
reviewed and either closed or reopened.

> Table:
> -> Contacts etc
> -> Summary stats
> -> Really useful links: "Open bugs" "Important bugs"
> Is also useful for hackers

Good point about it being useful for hackers.

> Separate page:
> -> "Old NEEDINFO"
> -> "Needs QA"
> -> "Needs versioning"
> -> "Needs confirming"
> -> Separates out products
> Mostly useful for QA

I'd argue that confirmation is useful for everyone, but otherwise,
sounds reasonable.

> Separating components in the table would suck because it would make the
> table huge.

Yeah. Maybe some threshold? 'components larger than X bugs get broken
out separately' or something? We do need to figure out what products are
too big for single hackers to help out with and how to break them down.

> > Hrm... that's all I can really think of offhand. Seems fairly
> > straightforward, and seems like a small enough number that we can use
> > your table layout, Andrew. Thanks. Maybe I'll find some time to
> > implement a first cut tomorrow.
> > 
> > Other random thoughts- how do we deal with components in the table?
> > Like, having a giant whopping 'nautilus' entry seems... painful. Ditto
> > for applets or utils. 
> 
> That's why it could be useful to have a separate page for each product
> as well as the table.

Reasonable. I'm not opposed to per-product breakouts- we just need to
make sure that the main page is useful to team leaders and at the right
granularity.

> > Oh and random brainstorm- maybe the solution for the need for a 'triage'
> > keyword is to have an UNTRIAGED priority, that things would default to,
> > and then we just keep an eye on the field? [It'd then be fairly easy to
> > have an 'UNTRIAGED' stat in the bug table.] Just a thought...
> > 
> 
> Is there a separation issue between triaging bugs coming into bugzilla
> ("New bugs today" - we do _try_ to catch them there) and the product QA
> teams? ie. Are they doing slightly different jobs? (I think they are)

The problem is that it isn't 'they' right now. It's me, and everybody
else. The group of people who do prioritization and stuff needs to get
much larger, and I hope all the experienced people on this list want to
join in.

> If so, remember that we need that flexibility in bugzilla (I'm really
> trying to say is we need _something_ that only QA people set otherwise
> they lose track of bugs).

<nod> So, suggestions? I don't want it to in any way that implies that
any type of triage has taken place- only initial verification, sanity
checking, etc. Maybe this is the role for the distinction between
UNCONFIRMED and NEW, and then
NEW+UNTRIAGED->NEW+[Immediate|Urgent|High|Normal|Low] is the distinction
for the more expert QA volunteers?

Luis