db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Jirs field definitions [was: Re: Triaging bugs, was: IRC meeting for bug review and High Value Fix list]
Date Fri, 22 May 2009 16:33:03 GMT


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

  - 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

  - "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


View raw message