Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Date: Mon, 22 Jun 2009 14:51:18 +0200
From: Dag.Wanvik@Sun.COM (Dag H. Wanvik)
Subject: Re: Jira field definitions
In-reply-to: <x1oxy6rklbm6.fsf@sun.com>
Sender: Dag.Wanvik@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x1oxtz28l9dl.fsf@sun.com>
References: <4A159C28.2000003@sbcglobal.net> <4A15AF13.5000209@sun.com>
 <4A16ACF7.4070907@sbcglobal.net> <x1oxy6spt7wg.fsf_-_@sun.com>
 <x1oxr5xknt99.fsf_-_@sun.com> <4A3914AF.4050104@sun.com>
 <x1oxy6rklbm6.fsf@sun.com>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (usg-unix-v)


Hi,

posting a new version incorporating comments I have received so far,
thanks everyone! If not further comments arise, I will put this
version up for a vote in a day or two. Process issues are decided by
simple majority and the vote should run for at least 72 hours
(http://www.apache.org/foundation/voting.html).

I do think Kathey is right that we may still need to tweak the
definitions a bit as we go along in the triaging process, but perhaps
it's still good to vote on this set of changes as a baseline. Smaller
changes later could be handled by lazy consensus.

Dag
----------------------------------------------------------------------
JIRA field proposal Version 1.0

Changes relative to proposal initial proposal: 
  (http://mail-archives.apache.org/mod_mbox/db-derby-dev/200906.mbox/%3Cx1oxr5xknt99.fsf_-_@sun.com%3E)

  - Changed severity numbering in "Priority" field (1 is most severe -
    Kathey)
  - rewording: customers -> users (Kathey)
  - "Derby Issue & fix info" renamed to just "Issue & fix info"
  - typo "Not" -> "Note" (Rick)
  - removed three "is this useful?" meta-questions
  - updated wording on "High Value Fix" field to contrast it to "Urgency".


Issue type : {Bug, Improvement, Task, Sub-task}
Doc: Use "bug" if the the issue concerns wrong product functionality. Use
"improvement" for all product enhancements that can not be classified
as bugs. Use "task" for process issues, e.g. work with releases. 
All the three issue types can have sub-task issue types.

Comment: We will not use "Wish", "New Feature", and "Test" issue
types. Use "Improvement" where you previously used New Feature. The
rationale for the merge is that it is hard to use these two issue
types consistently, and they often overlap.

Summary: String
Doc: 
      - 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.
      - Use of keywords in the title is good, to the extent they do not
        duplicate component information. 
Comment: no changes


Priority: {Blocker, Critical, Major, Minor, Trivial}

Doc: This is technical severity and not really a priority (see Urgency
field for that property).  Think of these values as severity 5 (trivial;
least severe) to severity 1 (most severe: blocker). Typically, this
field will not change unless more information about the bug becomes
available from investigation or from users. Its value is normally
not changed by release and scheduling decisions. Note that users
reporting bugs are liable to interpret this field as priority for
themselves, so developers should be careful to explain why we change
the value when we do. The value should reflect how hard is is to live
with Derby ("hassle") as long as this bug exists. Some key questions in
when trying to set this value (reflecting approximate decreasing severity)

     - Is data corrupted?
     - Is data lost?
     - Is a crash involved (reduced availability of data)?
     - Wrong query results?  
     - performance unexpectedly low?
     - Is a work-around possible?
     - Is it merely a nuisance?

Comment: Unfortunately, we can't change the name or the the values as
long as we share JIRA installations with other Apache projects.
Five levels of severity may be too much, but since we are stuck with
the values we might as well use accept that they will be used.

Urgency: {None, blocker, urgent, normal, low} 

Doc: This is the field used for dynamically reflecting scheduling
opinions and decisions; when a release manager is appointed, typically
a release manager will "own" this field to reflect how she sees how
issues should be prioritized for fixing prior to a release
("releasability"). Presumably, no release will be made if there is a
"blocker" left. This field also takes likelihood of users hitting a
bug into account; Priority a.k.a. Severity does not.  After bug
triage, no bug should have the "none" urgency.


Comment: See also "High Value Fix" checkbox


Due date: Date
Doc: not used

Components: {Unknown, 
             Build tools,
             Demos/Scripts,     
             Documentation,
             Eclipe plug-in,
             Javadoc,
             JDBC,
             JMX,
             Localization,
             Miscellaneous,
             Network Client,
             Network Server,
             Replication,
             Services,
             SQL,
             Store,
             Test,
             Tools,
             Web site}
Doc: After bug triage, no issue should have the "unknown" component.
     Several components can be selected to express a "and"
     relationship, e.g. "Test" && "Store".
     "Localization" includes "internationalization".

Comment: Newcomer moved to Bug Behavior Facts check-boxes
         Performance moved to Bug Behavior Facts check-boxes
         Regression Test Failure moved to Bug Behavior Facts check-boxes
         Security moved to Bug Behavior Facts check-boxes

Affects version: {Unknown, Released versions, Unreleased versions}
Doc: 
Comment: no changes

Fix version: {Unknown, Unreleased versions, Released versions}
Doc:
Comment: no changes

Assignee: DeveloperName
Doc: To assign yourself to an issue you need to be registered as a
     developer. Ask one of the committers about this on the mailing
     list derby-dev@db.apache.org
     (http://db.apache.org/derby/derby_mail.html).

Comment: This fields serves two functions, it synchronizes work so
         that two people can avoid working on the same issue, and
         second, it allows due credit to be reflected after the work
         is done. If there is more than one person contributing to the
         work, the main contributor will be the one assigned.


Environment: String
Doc: For example operating system, software platform and/or hardware
     specifications (include as appropriate for the issue), including:
     - JRE version
     - Output of org.apache.derby.tools.sysinfo (derby version info)
Comment: no changes

Description: String
Doc: Should be used to give all possible details of the issue in
     question.  If the issue you are filing is a bug, please include
     the following details in this field:

     - How to reproduce the bug (either step-by-step information or
       attach a reproduction script/program)
     - Chained nested exceptions reported by Derby and the SQLSTATE
       reported by the system
     - In a client/server scenario, also include any stack trace found
       in derby.log if available.

Comment: 

Original Estimate: *w *d *h *m
Doc: Not currently used


Issue & fix info: boolean check-boxes
     High value fix
     Known fix
     Newcomer
     Patch available
     Release note needed
     Repro attached
     Workaround exists
Doc: These yes/no check boxes relate to process 
     High value fix: This issue represents a potentially high return
                     on time investment based on:

                     - Frequency and likelihood the issue might be hit
                     by users.
                     - Estimated difficulty of fix ("bang for the bucks")
                     - Risk to existing users if the fix is
                     implemented.
                     - Severity of the issue (see "Priority" field")
                     - Availability of a workaround (see also "repro
                     attached" check box)
                     - The amount of user/developer time is wasted by
                     the issue.
                     
                     In contrast to the "Urgency" field, "High value
                     fix" is typically *not* used to reflect
                     scheduling decisions for a particular release,
                     but can be thought of a a longer term ("trunk",
                     "next major release")  consideration. For
                     example, even if a bug is not slotted to be
                     included in a particular update release, it can
                     still be useful to label it as something we want
                     to fix soon.


     Known fix: A comment describing a possible fix exists
     Newcomer: An issue suitable for a newcomer to Derby
     Patch available: A patch is available for this issue. This is
                      normally a sign that a code review is desired.

     Release note needed: The fix that went into the code changes
                          Derby's behavior, so that it may break
                          existing applications, or otherwise warrants
                          the user's attention.
                          Before the issue is resolved as fixed there
                          should exist an attached "releaseNote.html"
                          file in the proper format.

                          http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-8bfe22837d50a10f61f410c927336eabc682b62f

     Repro attached: The bug can be reproduced with code or steps
                          in a description attached to the issue or
                          described in the comments.
     Workaround attached: A described workaround can be found in the
                          issue, either in the comments or in an
                          attachment.
Comment: Renamed "Derby info" to "Issue & fix info" to distinguish
     from Bug Behavior Facts.
     Added "Repro attached" and "Workaround attached" and "known fix".
     Removed "Existing application impact".
     Can we merge the semantics of "High value fix" into "Urgency"
     perhaps?
     Moved "Newcomer" here from "Bug Behavior Facts".

Bug behavior facts: boolean check-boxes
     Crash
     Data corruption
     Deviation from standard
     Embedded/client difference
     Performance
     Regression
     Regression test failure
     Security
     Seen in production
     Wrong query result

Doc: The Bug Behavior Facts contain additional yes/no check-box
     characterization of the issue.
      
     Crash: Total loss of functionality. What this means depends on
            the Component. For example, for the database engine, it
            means it needs to be rebooted. For the ij tool, it could
            be a hang.  For the network server it could mean it does
            not answer or hand out new connections.
     Data corruption
     Deviation from standard
     Embedded/client difference
     Performance
     Regression: A bug that was not present in some previous publicly
                 available release.
     Regression test failure
     Security
     Seen in production: The bug is observed in existing
                          application code ("in the wild").
     Wrong query result

Comment: Renamed to "Bug behavior facts:" from Categories.
         Moved "regression" here from "Issue & fix info". Moved
         "Newcomer" to Issue & fix info.
         Added "seen in production".