Re: Bugtable: Feedback required

[Andrew Sobala <andrew sobala net>]

On Fri, 2002-08-30 at 00:02, Luis Villa wrote:
> On Thu, 2002-08-29 at 16:27, Andrew Sobala wrote:
> > Tell me what you think of this as a first draft:
> > 
> > http://www.penguins-of-fire.co.uk/test-bugtable.html
> > 
> > Note that half of it is fake, it's the layout we're talking about.
> 
> It's a good layout if there are only 4-5 stats we want to present. There
> might be more- i'm completely unsure. Offhand:
> 
> Total # 'open' bugs (maybe including needinfo?)

By the "Total" field I was actually thinking "Open." Maybe it needs
renaming.

> % 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. 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)

and others.

So

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

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

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

> 
> 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.

> 
> 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)

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).

> Luis

-- 
Andrew

It is now 00:46 local. I was probably incohhernt.