[kepler-dev] Bugs vs. Features

Matthew Jones jones at nceas.ucsb.edu
Wed Apr 2 14:57:34 PDT 2008


Agreed.  The distinction is important.

At NCEAS we actively use the 'Severity' classification for all issues. 
If an issue is an enhancement, it should be marked as such.  If it is an 
enhancement and not marked as such, we will generally go in and change 
it to reflect its status as an RFE.  The only issues that will 
definitely block a release are those marked as 'Blocker' or 'Critical'. 
  Others (Enhancement, Major, Normal, Minor) may be removed from a 
target milestone as we get closer to our target time and need to 
de-scope items. Discussions in the bug description about the severity of 
the issue are appropriate.

We only loosely use the Priority field.  Generally, Blocker and Critical 
bugs are P1, even if they are not marked that way.  The relative 
priority of Enhancements and Major bugs is a tossup, and we make 
decisions based on our priorities for a given release. Normal and Minor 
bugs frequently escape attention due to lack of time, even though we 
want to fix them.

Just yesterday we (Matt, Chad, Jing, Ben, Derik, Tim, Ilkay, Sean, 
David) just triaged the bug list in preparation for the release, which 
is why you saw such a large number of changes on one day.  If you don't 
agree with our decisions, please let us know, either in the bug or on 
kepler-dev.  But note that if you re-scope items that we de-scoped, we 
may ask you to do the work (we generally only de-scope things because we 
don't see a way to accomplish it with the time and people we have 
available).

How's that for a comment :)  Hope it clarifies my take on things.

Matt

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

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


More information about the Kepler-dev mailing list