[kepler-dev] Bugs vs. Features
tmcphillips at mac.com
Wed Apr 2 15:50:52 PDT 2008
I agree with you that these are useful distinctions and your opinions
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?
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?
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev