[kepler-dev] Bugs vs. Features

[Matthew Jones]

Oh, and one more thing.  'Target Milestone' is the key field in terms of 
what we are considering for a release. When we close a bug, we always 
check that the Target Milestone is set to the release in which that 
feature will come out. We have currently classified all issues into 
three milestones:

1.0.0          -- issues to be resolved for the 1.0.0 release
1.1.0          -- issues originally targeted at 1.0.0 that are de-scoped
                -- we'd like to finish them ASAP after 1.0.0, which
                -- is not always realistic
post-rel-1.0.0 -- items to be considered in a future version of Kepler.
                   These issues will be actively triaged for a Kepler
                   2.0.0 release as part of the Kepler/CORE project.

We will make other milestones as needed for various projects, but this 
is our working set now.

Matt

Matthew Jones wrote:
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~