Re: Bugzilla read to go live?

[Eli Goldberg <eli eazel com>]

Just wanted to add a few words... (everything else I'd have said has been
said by other people who are much more familiar with the GNOME bug process,
and I've been totally swamped with Nautilus testing...)

Owen Taylor wrote:

> Maciej Stachowiak <mjs eazel com> writes:
>
> > Sorry for being so late to comment on the new bugzilla. Here's a few
> > suggestions. They mostly come down to "make it more like the
> > Eazel/Helix customized version", but I think some of the changes that
> > Darin, Ramiro, Eli and others made are worth having:
> >
> > * Add a "bugzilla helper" as the preferred and more prominent way to
> >   file new bugs: http://bugzilla.eazel.com/helper.html for an
> >   example. This has helped both Mozilla and Nautilus improve bug
> >   reporting quality.
>
> This looks good. If you get someone to send me the source
> (assuming there is any but that one HTML file), I'lll look
> into integrating it.

You'll find that to be a very savvy decision. Christine Begle's Bugzilla
helper did more to improve mozilla.org's bugs than everything else we did.

If you integrate it, you'd be best served by taking the version directly
from www.mozilla.org. It comprises two files:
    http://www.mozilla.org/quality/help/bugzilla-helper.html
    http://www.mozilla.org/quality/help/bugreport.js

    (I did the Eazel adaptation by teaching myself JavaScript during the
bus trip to work, and then tweaking it that morning. The JavaScript wasn't
meticulously documented, I haven't programmed seriously in years, and I'm
sure I busted it in the process.)

>
> > * 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 was at Netscape from 1997-2000 (from where these Bugzilla resolutions
came) and they were not desirable from a tester's point of view. Here's one
example of how this worked for the Netscape image library:

    * A product release (e.g. Navigator 4.0) finishes up.
    * In order to meet the deadline, a lot of bugs that deserved to be
eventually fixed (but for which nobody had time right then) get marked
"LATER" or "REMIND", so that they get fixed later. Often, bugs that will
never be fixed are marked as LATER, rather than WONTFIX, e.g., to placate
reporter.
    * Several years pass. A totally different group of people are now
working on the next major version (Netscape 6/mozilla 0.6). They have no
memory of which bugs were marked LATER or REMIND years ago, and everybody's
so busy that nobody remembers to query, check, and re-open the
still-relevant bugs. (Since a lot of WONTFIX-quality bugs are mixed in with
the LATER/REMIND bugs, even less incentive exists to comb through them.)

    -> The end result is that the unfixed bugs from that release get
forgotten, and a new group of people end up re-discovering and re-reporting
(most of) the relevant bugs.

Havoc also added:

>> I can see how it would be useful to have a QA team that went through and
>> checked whether bugs were for real and reproducible, moving them to
>> NEW if they were, otherwise to NOTABUG, NEEDINFO, or whatever. Then
>> this same team would move bugs from FIXED to VERIFIED.
>>
>> If maintainers are doing everything themselves, then UNCONFIRMED and
>> VERIFIED are both useless states probably, since those reflect a QA
>> process separate from the maintainer process.
>>
>> Anyhow, the logical conclusion of that is "enable with manual
>> configuration" if we're going to try to have a QA process, otherwise
>> remove UNCONFIRMED and VERIFIED.
>>

    Although I'm not informed enough about how the GNOME bug process works
to have an especially meaningful opinion, I do hope you'll consider leaving
in the VERIFIED state, as a 'hook' for GNOME enthusiasts who aren't
ubercoders to get involved in testing, and making it easy for such
enthusiasts to learn how to do it. In my anecdotal experience on Nautilus &
Mozilla:

    * I re-open (or find & file related "corner case" bugs) on about 20-25%
of fixed Nautilus bugs (!) from verification. Is it possible that many of
bugs like these are being lost in GNOME right now because there's no 3rd
party verification of the fixes?

    * Verification is an ideal avenue to encourage enthusiasts to try out
QA: you can do as little or as much work as you like, there's no long-term
commitment, you learn a lot about the product through verification, and
it's quite easy to do a basic verification. Or a hundred.

    There's been far less verification interest in Nautilus than Mozilla
(not sure why), however.  I wrote a tutorial on this subject for Eazel's
testing site, and it could be adapted for GNOME with 5-10 minutes of work,
such as if you wanted to include a link on your bugzilla page to encourage
volunteers, as well as Dan Mueth's "getting involved in GNOME", etc.  (The
tutorial is at <http://nautilus.eazel.com/testing/verifybugs.html>.)

    I'd be happy to even do it for you if y'all agree that getting
verification started is a good thing for GNOME, but am not familiar with
GNOME testing in general (but can certainly get any help needed from Maciej
or whomever.)


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