db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Jira field definitions
Date Mon, 22 Jun 2009 16:16:41 GMT
Rick Hillegas wrote:
> Thanks for posting this new version, Dag. Looks good to me.
>
> Regards,
> -Rick
>
I think it is fine too except we should remove the question:
Can we merge the semantics of "High value fix" into "Urgency"
     perhaps? ""
> 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