Subject: Bugzilla Guidelines
From: Sam TH (sam@uchicago.edu)
Date: Tue Mar 13 2001 - 23:49:56 CST
Ok, now that we have the new bugzilla, we should take advantage of
it. So, here are a bunch of idea for our use of bugzilla:
1. Every bug has an owner.
-------------------------
Actually, this is already technically true, but most bugs are owned by
user 11, who has " " for an email address. So, bugs need to have new
owners. This means:
If you are interested in a bug, assign it to yourself, and
If you are willing to take responibility for a component, you can get
all new bugs in the component assigned to you. If you do this, be
prepared to assign the bugs ruthlessly to anyone who show the
slightest interest in them :-)
Currently, the following components need loving homes:
All Front End
Be Front End
Editing
Export-LaTeX
Find/Replace
Import-RTF
Installer
L10N
Layout
Piece Tables
Preferences
Printing
Scrolling
Spell
TODO
If you want to adopt one, let me know.
I have taken the cruel and mean step of assining the X Front End to
Martin. Ha ha.
2. Nuking postponed.
--------------------
I don't like the postponed category, and Jesper said he doesn't
either. So I went through and reopened lots of the postponed bugs,
and added a few comments to some of them. Does anyone think that
postponed serves a valuable purpose?
Here's how I would classify bugs in postponed:
A. Real bugs. There were some crash bugs that I found there. This
isn't ok. Crashing is always a bug, no matter when or why.
B. Stuff we should do in the future. These are real requests for
enhancements, and should be marked as such.
C. Big stuff that's a long way off. These should be marked
CLOSED/WONTFIX. Bugs requesting table support go in this category.
D. Stuff that we are waiting on other people for. These aren't bugs
in AbiWord, and should be closed. For example, "AbiWord should do
what I mean, not what I say" is waiting on the artifical intelligence
community.
3. Put unfinished work in Bugzilla
----------------------------------
This ranges from significant projects (like, say, Word export) to
minor tasks. Break up tasks into sections, and use meta bugs and
dependencies to track how it all fits together. See how this gets
done in bugzilla.mozilla.org by looking at the dependency tree of
http://bugzilla.mozilla.org/show_bug.cgi?id=66967
Breaking tasks up into sections means other people can do the sections
for you, Wouldn't that be fun. :-)
4. Use keywords
---------------
Currently, we have three keywords, crash, assert, and rfe. Use them to
denote the appropriate kind of bug. And if you want new keywords, I
can add them really easily.
I have an additional proposal for a new keyword that I think should be
discussed: abiword1.0. This keyword would represent bugs to be fixed
before 1.0 is released. Of course, we want to fix as many bugs as
possible before 1.0, but we should indicate that these are the bugs
that are considered most important. Of course, all crash bugs are
automatically in this category.
5. Bugzilla Email
-----------------
Theoretically, bugzilla is capable of sending lots of email, and
keeping people informed about bugs they are interested in. However,
this doesn't appear to currently be working for us. I will be looking
into this. However, you can change your email preferences, so that
you get more or less email, and you can place yourself on the CC list
for a bug, so you get notified when it changes. Of course, the
reporter and assignee are always on the email list. Additionally,
Bill has asked for an email list for *all* new bugs in bugzilla, and
I'll see what I can do about that.
6. Future Directions
--------------------
Paul has suggested that we adopt Eazel's additional fields of
Inclination and Work Remaining. I am inclined towards adding
Inclination soon, but Work Remaining seems more controversial, and
needs additional discussion.
There is also the possibility of a bug reporting assistant, to help
our users report quality bugs. People interested in working on this
are encouraged to look at these examples:
http://bugzilla.eazel.com/helper.html
http://www.mozilla.org/quality/help/bugzilla-helper.html
This would be benificial, although not as much as it is to Mozilla,
where they have 75,000 bug reports. :-)
7. Other Stuff
--------------
If you want new, whiz-bang features in bugzilla:
$ cvs :pserver:anoncvs@cvs.abisource.com:/webcvs login
Password: anoncvs
$ cvs :pserver:anoncvs@cvs.abisource.com:/webcvs co bugzilla
Ha ha.
Seriously, I will consider feature requests, but making them to the
real bugzilla people (do this via bugzilla.mozilla.org) is more likely
to have an impact.
If you find bugs, I'm always happy to fix them.
There, that's long enough. :-)
sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dynds.org/decss
This archive was generated by hypermail 2b25 : Tue Mar 13 2001 - 23:44:08 CST