What are bugs? Are bugs really work items?

[Lisa Anderson]

I'm relatively new to Bugzilla; we've set it up here at work and have
been using it for the last 3 weeks and have been pleased overall.

The severity field has been a problem for us, however, and it looks like
others are struggling with it as well. In other situations I have used
the severity field as follows:

Severity * Likelihood = Priority.

We even got fancier and rated each component or feature as to the
development risk, i.e., how hard is it to fix, how much code is
involved, etc. The formula becomes this:


Severity * Likelihood * Dev Risk = Priority.

I like this method because using scales like the following takes the
subjectivity out of prioritizing bugs.

Severity:
	Blue Screen/Hang
	Loss w/o workaround
	Loss w/ workaround
	Inconvenient
	Enhancement

Likelihood (how often will the user - not the developer) run into this
problem:
	Always
	Usually
	Sometimes
	Rarely
	Never

Bottom line this means that it doesn't matter what you call the records
in Bugzilla - bugs, work items, feature enhancements, whatever. The
records now all become issues that need to be addressed some how, some
way before the product can be shipped. And, with the method above, the
records are properly identified as to their importance to the project.

LisaAn


-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org] On Behalf Of Christopher Hicks
Sent: Wednesday, October 06, 2004 8:40 AM
To: Bugzilla Developers Mailing List
Cc: Jay Glanville
Subject: What are bugs? Are bugs really work items?

On Wed, 6 Oct 2004, Jay Glanville wrote:
> The argument to not use the severity field to indicate feature work is
> because you might want to use the severity field for features.  For
> example, a feature could have a 'critical' severity to indicate the
> amount of work required, or a severity of 'trivial' to indicate it's
> just a small feature.
>
> Basically, the correct answer to this problem is to have a "type"
field,
> and to stop calling the items 'bugs'.  For example, all items are
'work
> items', and the type field had possibilities of: bug, suggestion or
> feature.  This would basically capture the situation in a nutshell.
> Hold on, if we changed 'bugs' to 'work items', does that mean we'd
have
> to change the name from Bugzilla to WorkItemZilla?  ;-)

This comes from a recent discussion on the webtools list.  Since this is
a 
question about the direction/future of bugzilla which I've had on my
mind 
and in my inbox quite often recently so I decided to bring this to the 
developers list.  Would the core devs be willing to share their thoughts

and feelings on this seemingly sensible question?

If I had more sleep I'd slip in something witty about the continually 
blurring semantics of bugs, but I'm not that coherent yet this morning. 
:)

-- 
</chris>

There are two ways of constructing a software design. One way is to make

it so simple that there are obviously no deficiencies. And the other way

is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=Lisa.Anderson@imcentric.com>