[kepler-dev] Bugs vs. Features

[Timothy McPhillips]

Hi Christopher,

I agree with you that these are useful distinctions and your opinions  
mainstream.

As I'm sure you are aware, a possibly orthogonal aspect is to what  
extent a system such as bugzilla is used as a project management  
framework in any particular organization.  At one extreme one can use  
bugzilla as a system for listing every development activity planned  
or ongoing, tracking what every developer is working on, detailing  
the dependencies between tasks, planning future feature sets, etc.

At the other end of the spectrum one can use bugzilla as a  
communication tool between a development team and a community of  
users (who may also be developers).  In this mode the community  
reports bugs and requests enhancements via bugzilla and the  
development team responds to these reports and requests and provides  
status updates via bugzilla, but all detailed project planning,  
internal discussions, task prioritization, etc, are managed some  
other way, and fewer of the bugzilla bells and whistles (e.g.,  
priorities) need to be used.

Either way (and anywhere in between), it certainly is useful to  
describe the policies and procedures for using such systems for a  
particular project (and to discuss explicitly what features are to be  
used in that project).  My bias is toward the latter approach (i.e.,  
as a tool for communicating with the community) because I feel that  
systems like bugzilla tend not to provide a sufficiently complete  
(and convenient) set of project management features (e.g., the  
hierarchical structure of projects and tasks is difficult to  
represent clearly), and use of them in the first mode leads either to  
redundant entry or loss of project management details.  It's a bad  
thing when a technology limits what you can say or think. On the  
other hand, I think how bugzilla is used in kepler development today  
does reflect how the collaborative effort actually works.

How about we discuss how we want to use bugzilla or similar systems,  
going forward, at the Kepler/CORE developers meeting in May?

Cheers,

Tim

On Apr 2, 2008, at 2:37 PM, Christopher Brooks wrote:

> Below is just my opinion, but I thought it would be useful to
> discuss this so that we are all on the same page.
>
> When adding something to bugzilla, it is useful to differentiate
> between bugs and enhancements.
>
> In my mind, a bug is problem with the current set of features.
> Common bugs:
>   - Crash or stack trace
>   - Incorrect results
>   - Documentation does not match reality
>   - Can't do something obvious
>
> An enhancement is missing functionality.
> Common enhancements:
>   - Demo idea
>   - Need a new actor that does xxx
>   - "It would be nice if . . ."
>
> The reason to differentiate between the two is that bugs
> should usually be handled before enhancements
>
> The issue is that it can be hard to differentiate between
> bugs and enhancements.  I usually use the litmus test of
> is the issue "wrong"?  If it is wrong, then it is a bug.
> If the issue is "missing", then it is an enhancement.
> One person's bug is another person's enhancement.
>
>
> I'll sometimes use the term RFE for Request For Enhancement.
>
> Bugzilla has these fields under severity:
> Blocker	   Blocks development and/or testing work
> Critical   crashes, loss of data, severe memory leak
> Major	   major loss of function
> Minor	   minor loss of function, or other problem where easy
> workaround is present
> Trivial	   cosmetic problem like misspelled words or misaligned text
> Enhancement	    Request for enhancement
>
> There are also priorities, where P1 is the most important.
>
> There is a social issue where when someone adds an issue to bugzilla,
> and someone else changes the classification, there can be hurt
> feelings because of the "one person's bug is another person's
> enhancement" issue.
>
> Any comments?
>
> _Christopher
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/ 
> kepler-dev