Hi,
I have started working on the definitions. Instead of making en entire
document, I'll hand out my proposed definitions (culled from other
source or invented by me) a little bit at a time, for digestability.
I'll collect all when we are through and put them on the Wiki.
OK, first installment:
-----------------------------------------------------------------
* Guidelines for triaging Derby JIRA issues
To keep the JIRA database as useful as possible, we want the
different fields in a JIRA issue to be used as consistently as
possible. This enables quicker identification of issues with
certain characteristics of interest, e.g.
- for a release manager to check that all show stopper bugs have
been addressed before a release
- for developers, preparing short lists of bugs to look at fixing
- se we can prune the database of old bugs that are not reproducible
- so we can make different kinds of statistics to measure trends
Practice over time has shown that Derby has many fields, but
sometimes it can be hard to be sure what value to give to a
certain field due to several reasons:
- lack of immediate information: some kids of information require
further analysis of an issue to be able to determine its value,
e.g. if a bug is a code line regression or not
- not obvious fields: how should I use the priority "blocker" vs
the urgency "blocker" value? What constitutes a crash?
- JIRA provides several ways to achieve the "same thing",
e.g. sub-tasks vs. "is-part-of" links.
Furthermore, values can be inconsistent due to users filing
issues without necessarily reading the instructions (well), and
even if they do, instructions are not up to date.
Generally, the JIRA database is a tool for developers, so we should
not shirk from editing user's setting of priority, urgency. If we do
change the user's setting, we should explain in a comment why, though.
This is an attempt at clarifying meanings of fields, and also to
provide hints for filling them out. The guidelines are intended for
committers and developers to help keep usage in line.
* Title:
- Make as descriptive as possible, but try to avoid using very
long lines. It's usually better to give more detail in the
description.
- For bugs, describe the problem or symptom seen, not its solution.
Sometimes, when working on a bug, the underlying problem turns out
to be different then symptom indicated in the title. In such
cases, keep the symptom description (but it's good to make it
clearer!) since this will decrease duplicates later.
Use of keywords in the title is good, to the extent they do not
duplicate component information.
* Issue type
- "Bug" is pretty obvious.
- Use "Improvement" for improving an *existing feature*, and "New
Feature" when it is a new user functionality. Example: allowing an
alternative keyword in the syntax is an improvement, not a new
feature. Replication is a new feature, but the limit can be hard
to fix sometimes, granted.
- "Task" (in contrast to sub-task) is for stuff that is not a bug,
for example code cleanups that do not result in changes in
behavior.
- "Test" is a bit awkward, since but we also have a *component*
called "Test" (the component "regression test failure" will go
away, being replaced by the corresponding flag).
The wording in [1] is:
"An entry regarding a test (unit, integration, system, stress
etc.) including requests for new tests."
The "regarding" wording above seems to cover all issues,
including bugs and improvements. *But*, more issue types than
"Test" are used by the "Test" component issues, though. Usage is
mixed here.
QUESTION 1: Is the issue type "Test" redundant since we have a
component called "Test"?
QUESTION 2 (if answer to Q1 is "no"): should any test component
issue *not* use issue type test, and if so, when? For "Bug"?
For "improvement"? For "new issue"? The first two of these are
common, the last is used only in three instances.
- "Wish": is for user wishes, I think. Should mostly be reclassified
as issue type "new feature" or "improvement" if we agree it's a
reasonable wish.
* Priority
Listed in [1], we have (quote):
- Blocker: Show-stopper! Blocks development and/or test work. No
work-around possible. Needs to be worked on right away.
- Critical: Severe issue that potentially has a work-around but may
not be acceptable under all circumstances. Includes issues such
as system crashes, loss of data or severe memory leaks. New
features & improvements in this category are required urgently
but not ASAP.
- Major: Issue has a work-around but there is a major loss of
functionality. For new feature/improvements, this needs to be
implemented soon (but not urgently)
- Minor: Some loss of functionality. Work-around exists. For new
feature/improvements, there is no urgency with the implementation
of this request.
- Trivial: Lowest priority. No loss of functionality. No hurry to
fix/code this. Mostly a cosmetic issue like misspelled words or
misaligned text
* Urgency
Nothing in [1]. My suggestions below.
- Blocker: We won't make a release if this one isn't fixed
- Urgent: Should preferably be fixed before a release is made
- Normal:
- Low: No need to hurry about this one
Note that "Blocker" is also a priority. So how to use {Priority X
Urgency} ? It is not obvious how priority differs from urgency.
A tentative definition is "Priority" is more akin to severity, that is
its related to the product code independently of popularity and
release plans etc, whereas "Urgency" is used as a scheduling tool, and
the urgency of a bug can be changed over time. These two fields are
not completely independent, I think. Please help flesh put instruction
for how to use these two!
Should the Priority definitions be revised now that we have urgency?
Note that the definition for priority "major" uses the word
"urgently".. ;-)
[1] The business of Filing Apache Derby Issues in Jira
http://db.apache.org/derby/binaries/FilingDerbyIssuesInJira.pdf
Dag
