This note contains instructions for starting with Bugzilla
and some remarks on how to use it.

1. Setting up a Bugzilla account

The project's Bugzilla is at

http://ricardo.ecn.wfu.edu/bugzilla/

The first thing to do is setup your Bugzilla account:
(i) From the root page, click on "Open a new Bugzilla account".
(ii) Use your "ricardo" email address (not essential, but preferable).

An email will be sent to you containing the Bugzilla password.
Follow the instructions. It is probably best to change it to
your "ricardo" password.

2. Submitting bugs

(i) From the root page, click on "Enter a new bug report".
(ii) For most bugs the only fields you need worry about are:
     - the "summary" field, and
     - the "description" field.

The "assigned to" field allows a bug to be initially assigned
to a specific individual. Otherwise, leave it empty, and the bug will
be assigned to cvsusers@ricardo.ecn.wfu.edu (i.e., all of us).

The summary field appears as the header of the bug email that gets
sent, so make it short but descriptive. For example, if it is a trivial
typo then begin the summary with "typo". Or if it is more substantive,
try things like "content problem", or whatever is most suitable.

The description field should describe the problem in sufficient
detail to be able to fix it.

When done, click "commit" and the bug enters the database.

3. Bug status changes

A bug can be in various states, which you can control.
The most common state change is declaring a bug is FIXED.
When a bug is fixed it will not appear in any queries
(although it remainds in the database).


NEW      - new bug, unassigned to any specific individual.
ASSIGNED - assigned to a specific individual, who claims
           ownership of it (this prevents more than one person
           simultaneously trying to fix a problem, so it's always
           worth assigning a bug to yourself if you plan to fix it).
FIXED    - bug is squashed.

There are other status changes, such as INVALID, WONTFIX,
LATER, REMIND, WORKSFORME, which are reasonably self-explanatory,
some of which may prove useful, others won't.

4. Bug queries

(i) From the root page, click "query existing bug reports".
(ii) This page is complex. Ignore it. Simply click on the
"search" button. By default this displays all the new bugs
(and does not display the fixed ones). When you begin to care
it may be worth paying notice to the other options on this page.

Once you have a list of bugs, you can select one to examine,
change its status, add a note etc. Alternatively, you can
simply click on the hyperlink in the bug email that you receive.
That will take you straight to the bug report.

That's all you need to know to start using Bugzilla.

5. Recommended use

Bugzilla is intended for software projects. So there is some
mismatch between how we will use it and its design, but not
much.

The general rule is to post a bug if the reporter cannot easily
fix the bug themselves. 

The main advantage is that more things get noted, less things
get forgotten, and more good things get done.

A bug can have multiple notes appended to it by multiple users. 
This can function like a discussion thread. So apart from posting 
clear bugs like bad grammar, clumsly sentence construction, 
and the like, it can also be used to post content criticisms. 
For example, I may report a bug that questions an assertion 
that is made:

Bug summary: "Content problem: theory of moon's surface"
Description: "This paragraph claims that the moon is made 
of cheese. I'm not sure. I think it is generally agreed 
that the moon is made of mustard."

The person responsible for the content can then decide
to fix the bug, or add a further note:

Additional comments: "No, no, it has been shown definitively 
in ref [2] that the moon is, in fact, cheese".

And so on, until the bug is resolved.

It can also be used to post reminders, or TODO points.
For example:

Bug summary: "Missing figure for moon's surface".

Etc.