Dag H. Wanvik wrote:
> Hi all,
>
> I enclose a proposed overhaul of the Jira fields to ease our bug
> triaging.
Thanks Dag. Comments in-line.
> There are changes on several levels:
>
> - Update documentation for some fields
> - Add some fields
> - Modifying some fields
> - Merging or (re)moving some fields
> - Stop using some field values (we can't modify fields we share with
> other users of our JIRA installation)
>
> I have tried to incorporate comments I have seen so far, but I'm sure
> I missed some things, so please add your comments and I'll try to fix
> it. I will update "Tips for filing Apache Derby Bugs" to reflect our
> conclusions, if we reach any ;-) I don't document every field here,
> only the ones which I find non-obvious or that we have been
> discussing.
>
> I use the following format below:
>
> <field name> : <type>
> Doc: <documentation>
> Comment: <discussion comments, rationale, questions>
>
> Dag
>
> -----------------------------------------------------
> Issue type : {Bug, Improvement, Task, Sub-task}
> Doc: Use "bug" if the the issue concerns wrong product
or test
> 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 1 (trivial;
> least severe) to severity 5 (most severe: blocker).
Perhaps it is just what I am used to but I tend to think of a Severity 1
as a blocker down to Severity 5 as trivial.
> Typically, this
> field will not change unless more information about the bug becomes
> available from investigation or from customers.
I would replace customers with users.
> Its value is normally
> not changed by release and scheduling decisions. Not 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 triage, no
> bug should have the "none" urgency.
>
> Comment: What is the relationship between this field and High Value
> Fix flag? Could it subsume High Value Fix?
>
>
I think it could, but there are fairly hard issues like DERBY-700 and
DERBY-1433 which may not have a high urgency with regard to a specific
release but are very important because they are ticking time bombs or
bombs that have already gone off. These issues might have a higher
urgency for 10.6 than 10.5.2 but development is going on for both and we
don't have a release manager for 10.6 yet, so how should they be
evaluated in terms of Urgency?
> 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
>
>
> Derby 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.
> - 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.
> 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.
>
>
It would be good to refer to the Wiki page regarding making release note:
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 "Derby 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?
>
Yes, if we can resolve the issue of multiple releases going on at once.
> Moved "Newcomer" here from "Bug Behavior Facts".
> Is "workaround attached" useful? (suggested by me)
> Is "known fix" useful? (suggested by Knut)
>
> 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 "derby issue & fix info". Moved
> "Newcomer" to Derby issue & fix info.
> Added "seen in production".
> Is "seen in production" useful (suggested by Myrna)
>
>
I think "Seen in production" is useful.
|