db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Jira field definitions
Date Mon, 22 Jun 2009 16:01:21 GMT
Thanks for posting this new version, Dag. Looks good to me.

Regards,
-Rick

Dag H. Wanvik wrote:
> 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".
>   


Mime
View raw message