Re: Bugzilla read to go live?

[Owen Taylor <otaylor redhat com>]

Gregory Leblanc <gleblanc cu-portland edu> writes:

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

Tracking which bugs have had responses to the submitter is something
that is in fact important. Timely responses to bugs is something
that is important to customer satisfaction.

However, I see the assigned status as indicating that the person
the bug is assigned to has taken responsibility for actually fixing
the bug. I'm not sure piggy-backing onto that whether the bug
has been looked at all is appriopriate.

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

Perhaps my trouble with the field is also in the wording. Not only
does it look rather unprofessional, it also simply doesn't correspond
to how things work for me - the bugs I hate fixing, I probably need to
take of myself, because nobody else is going to be able to fix
them. While the bugs that would be fun/easy to fix are frequently the
things that I can get other people to do.
 
I think Martin's original idea of a "Volunteers" keyword corresponds
better to what I'd like to flag 
"Here's a bug that somebody could pick up even if they don't know
a whole lot about GTK+." And I think this is general. 

To bad the Bugzilla keyword interface is so cryptic. (We need
nice little flags you can stick on bugs like in Nautilus...)

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

Your descriptions here are for severities, not priorities. Priorities
are for maintainers to track which bugs they should be working on, not
how bad the bug is. A Urgent bug could simply be mispelling a
contributors name or some such embarassing but not criticial bug. A
Low priority bug might be one that affects functionality in a serious
way but is a huge amount of work to fix.

[....]

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

There is an "enhancement" severity; note that priorities are
maintainer only - the don't describe the bug, they describe
what the maintainer is going to do about it.

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

As I said, a Low priority bug could well be things like redoing
the rendering model for GTK+. What you'd really want here is Eazel's
time estimate field, though low severity bugs may correspond in
many cases.

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

Three separate levels above the "next milestone" level? This
seems to go against release-early release-often...

And if there are enough more-urgent-than-urgent bugs that they need
tracking....

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

Without looking up, there is no way that I could tell you what the
priorities all mean, even after just reading them. And the 
descriptions above are very specific to Eazel's particular release
scheme. I would have to invent something different for GTK+
and if different projects have different definitions who is
going to be able to understand the numbers then?

I think simplicity here is a virtue.
 
> 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.

Priorities are just names. It could be PO-P5 and UNKNOWN, but since
we have the ability to make them human-meaningful names, I'd rather
make them all human meaningful.
 
Regards,
                                        Owen

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