What are bugs? Are bugs really work items?

[Mick Weiss]

I'm not sure if anyone else has used "Eventum" - from the folks who 
wrote MySQL. This has one cool feature - the ability to create custom 
fields in the priority drop down. the only problem is that you *need to* 
define them yourself and there are no defaults.

Then again this is also possible with Bugzilla - but it just takes a 
little more work. The other thing is that Eventum is more for "Issue 
tracking" and not really for software development bug tracking.

I actually use both Eventum and Bugzilla to keep those two things separate.

I guess the idea is to use the right tool for each job.

Best Regards,

- Mick

(o> Web / software developer
( )     UNIX Systems Admin
---   ~ www.mickweiss.com ~



Lisa Anderson wrote:
> 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. 
> :)
>