Re: Bugs in Bugzilla

[Maciej Stachowiak <mjs eazel com>]

Cc'd someone who can help explain..

Havoc Pennington <hp redhat com> writes:

> Hi,
> 
> When bugzilla.gnome.org sends you your password, it tells you you can
> change it at bugzilla.mozilla.org. 
> 
> The default permissions for new accounts lets anyone change any part
> of a bug; instead I think only maintainers of a package should be able
> to change bug status by default.
> 
> It would seem simpler to merge Platform and OS into a single field;
> also, some of the OS options are pretty nonsensical for GNOME.
> 
> I don't see the point of having both Priority and Severity; I think we
> have Priority turned off for Red Hat. Eazel was using Priority I guess
> - what do you guys do with this field vs. Severity?
> 

Priority and Severity mean different things. In canonical QA parlance,
Severity is a way of measuring how bad an effect a bug has on the
user. Priority is a measure of how important it is considered to fix
the bug relative to other bugs, and used to determine what things are
most important to work on, what things can slide to a future milestone
or release, etc. Many organizations mandate that bugs of certain
severity should be at least certain priority (for example: crashes
must be at least P1, bugs resulting in loss of user data must be at
least P1, etc).

It is generally considered bad for the average bug submitter to set
the Priority since doing so requires judgement; I'd say in the context
of Gnome the package maintainer or their designated representatives
should do this.

At Eazel, we only use the Priority, and replaced the severity field
with time estimates of how long it will take to fix the bug, so we can
use this to do project planning. Ultimately, Priority is used to drive
the work and Severity would be purely informational and just one
factor used to drive setting the Priority; but it can be a useful
piece of information.

Oh yes, we also need to consider what milestones to set, and how to
assign bugs to milestones. Maybe we only want milestones for actual
Gnome releases, maybe each package wants its own milestones, etc.

And we need to figure out whether we want to use the various bugzilla
keyword features and if so how (at Eazel we turned those off).

We should definitely figure these issues out before we start using
bugzilla because it will be a royal pain to change later.

While I know we all want a better bug tracker, let's take a bit to
figure out what policies we want before jumping over.

 - Maciej