[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