Re: Bugzilla read to go live?

[Maciej Stachowiak <mjs eazel com>]

(I must have snipped the part about bugzilla helper - I'll ask Eli for
the source).

Owen Taylor <otaylor redhat com> writes:

> I think I said this earlier in some mail, though I couldn't find
> it last time I looked:
> 
>  Priority, Severity, and Time estimate are not 3 independent
>  fields. Priority is a computed function of Severity and Time
>  estimate - unfortunately one that has to be computed by 
>  a person.  
>  
>  Because of this, including all three gets unwieldy and confusing, since 
>  there is duplicated information. There is value in all three,
>  but I'm not sure that the marginal increase from adding
>  a third is worth the increase in complexity and confusion.
> 
>  Which 2 out of the three do I favor? I think priority is definitely
>  useful for managing a release; the other two are both less
>  important - partly because they both can be conveyed fairly
>  well in the text of the bug. 
> 
>  But I think we probably need to keep severity - if no other
>  reason than it corresponds to the fields for existing bugs
>  in debbugs fairly well.  

I don't think this makes sense. Severity is how serious the effect of
the bug is on the user. Priority is how important it is to get to it
soon. Time estimate is about how much work the bug will take. These
three are often related, but certainly not so strongly that you can
compute one from the other two.

Say someone has a bug that causes instant crash on startup - this
needs to be both high priority, because it blocks all work, and high
severity. But how can I tell from this info whether the assignee
thinks fixing the bug will take two hours of work or a week of work?
Basically I can't. So I don't see how your argument works, at least so
far as leaving out time estimate goes.

I also don't think time estimate is useless for managing a project
(amount of work remaining is about the most critical piece of project
management information), or conveyed equally well in the text of the
bug (because you can't do totals that way, for one thing).

>  
> > * Add the inclination field as on buzilla.eazel.com - it helps people
> >   who are searching for bugs to grab know which ones people would most
> >   like to have taken off their hands.
> 
> I hate it! :-) I personally don't think that the inclination field is
> useful for the typical open source project where people will be
> assigning bugs to themselves, and as such, I think it is just
> clutter to include.

Hmm, I guess this raises another issue about project management. For
bugs on the Eazel bugzilla. we gently prod people who leave their bugs
NEW isntead of marking them ASSIGNED or reassigning them. Leaving a
bug NEW means you have not looked at it at all, and thus is considered
antisocial behavior.

If the GNOME bug tracker instead has a policy that it's OK to leave
bugs around without looking at them, I guess inclination is somewhat
less important, except maybe for people who take responsibility for
their bugs but might still want to give some away if possible..

> > * Consider revising the priority and severity fields. The priority
> >   fields have no definition at all, let alone one that makes clear
> >   what kinds of bugs should be release critical (note that sometimes,
> >   even an Enhancement is release-critical). I think the priorities
> >   (P0-P6) that we have on bugzilla.eazel.com are more useful, see the
> >   definitions here: http://bugzilla.eazel.com/bug_status.html#priority
> 
> The priorities do have definitions, I just forgot to put them
> onto the page.
> 
> What I wrote earlier was:
> 
>  Urgent
> 
>    This bug requires immediate attention and a new release of the
>    software as soon as possible. This will typically be used
>    for security problems.
>
>  High
> 
>    This should be fixed for the next release of the software.

This really isn't enough granularity. It doesn't distinguish bugs that
currently block all work (but e.g. have been introduced since the last
release) from bugs that should be fixed as soon as possible in general
from ones that need to be fixed by the next release.
 
>  Normal
> 
>    [ If someone wants a definition for this, they need to give
>      it to me. ]   
>   
>  Low
> 
>    This bug would be nice to fix as time permits.
> 
> P0-P6 are just confusing, you can't even tell which is more
> prioritized. There was mail from Ghee Seng Teo earlier indicating
> he thought at least P5 and P6 were not used at all on
> the Mozilla project.

We use all of P0-P6. We don't use the same definitions as
Mozilla. Here they are, for reference (I corrected some things
relative to the definition page):

P0  fix now; everybody is stuck until this is fixed
P1  fix right away; this bug is a big embarrassment
P2  fix soon, can't wait for the next milestone
P3  fix for the next milestone
P4  fix needed for release and planned for the next milestone, but we
    are willing to let it slide to a later milestone
P5  planned for the next milestone, but we are willing to let it slide
    to a later milestone or from the release entirely
P6  bug has not yet been prioritized; could be a P0 or a P5, who knows?

Also, lower P-number being higher priority is a pretty industry
standard thing. And once you know the direction, the order is pretty
clear.
  
> > * Adding something like the summary reports page on Eazel's bugzilla
> >   (http://bugzilla.eazel.com/reports.cgi), this is really useful for
> >   seeing who is how doomed, whether people are marking their NEW bugs
> >   assigned, how much total work is in the milestone, etc (we'd
> >   probably want this customized to let you specify sets of packages
> >   you care about for a summary).
> 
> That's just a matter of a bit of work to get reports.cgi going
> again - its a standard bugzilla feature.

Our version is enhanced by being able to filter by priority as well as
milestone, and by including total time estimates, among other things.
 
> > * If this does not already exist, it would be really useful to have a
> >   way to set milestones per product.
> 
> Hmmmm ... I guess the question is how much you view bugzilla 
> as a product management tool. The milestone infrastructure
> is there, just removed from the forms.
> 
> Milestones perhaps are a little funny for something like GTK+
> which has both a stable branch and a HEAD branch. I guess as a
> goal we could have it so if you define milestones for a product
> you see them on the interface for that product, otherwise
> you don't. That might take a few hours of hacking.

Hmm, bugzilla wouldn't be very useful for a at least my needs if it
couldn't be used for project management. I don't know how other people
feel. I can also imagine GNOME releases wanting to have milestones for
the various freeze points and betas and such at least (once we have
those established).

> > * I suggest removing the LATER and REMIND resolutions. I don't think
> >   these are useful (according to their definitions they aren't even
> >   resolutions really - the right thing to do with bugs that match such
> >   criteria is to bump them to a later milestone).
> 
> I would agree here - bugs should not be marked resolved if you
> want to work on them later. I certainly have no intention of
> using them. (And I think having _both_ LATER and REMIND is really
> confusing.) What do other people think?

I asked some former netscape folks about this and they said it's to
let you avoid seeing a bug without having to fix it - I tend to think
this is a bad thing.

 - Maciej


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers