Re: Bugzilla read to go live?

[Gregory Leblanc <gleblanc cu-portland edu>]

On 10 Dec 2000 00:27:39 -0800, Maciej Stachowiak wrote:
> Owen Taylor <otaylor redhat com> writes:
> > > * 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.

Since I'm not the maintainer of a package, I can't say how much they'd
hate this, but as a bug reporter, it's certainly nice to see that
somebody has at least looked at my bugs.  

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

If inclination gets kept, I think that it needs to be in terms of how
badly the person wants to get rid of the bug, and not how much they
like/dislike it.  It doesn't exactly feel all that good to have somebody
say that they "hate" your bugs, but if they say "I'd love to have
somebody take this off my hands" (or however somebody can phrase that),
it's much better.  

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

I like some of what Telsa had to say when she wrote the docs for
bug-buddy, so I've tried to come up with a slightly improved version.
I've done something similar for the ones below as well.  

Urgent

    This bug makes other software or the entire system break, causes
    serious data loss, or introduces a security hole on the system.  It
    needs to be fixed and a new release of the software made as soon as
    possible.



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

High

    This bug makes the software unuseable or mostly so, or causes data
    loss.  Programs crashing on startup, or crashing and leaving files
    named "core" in your home directory are probably "high" priority.

> >  Normal
> > 
> >    [ If someone wants a definition for this, they need to give
> >      it to me. ]   

Normal

    These are all the bugs that you can't fit into other categories,
    such as errors in the program (computing the value of 2+2 as 22),
    messages that give incorrect information, and other bugs that aren't
    purely cosmetic.


> >   
> >  Low
> > 
> >    This bug would be nice to fix as time permits.

Hmm, I seem to have misplaced a category, I thought there was a place
for "wishlist" bugs, is this gone?  It would be nice to have a
designated place to put RFEs (requests for enhancement).
Low

    These bugs are cosmetic, or other bugs that won't affect the use of
    a program.  These bugs will get fixed as time permits.

I'd also like to point out that "low" priority bugs may be a good way to
get people involved who want to start with something small, so that they
can get a feel for the project.  

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

Is there any way to make it P0-P5, and make P6 NOT the next one in
series?  This would make it clearer that P6 isn't part of the normal
prioritization scale, but rather a place for bugs that haven't been
fitted to that scale yet.

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

Will the Eazel and Helixcode GNOME products that are in their bugzillas
be moved into the GNOME bugzilla at some point?  I find this
fragmentation a real PITA, as I have to look several places for bugs as
well as for mailing list archives.  It doesn't really show GNOME as a
unified force if companies are hosting stuff their own way, although
with the old bug system that's understandable.  

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


This sounds like a pretty solid "we don't want these", and I tend to
agree.  Anyway, I think that's enough ranting from me, thanks for
reading,

    Greg

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