Hi all,
I enclose a proposed overhaul of the Jira fields to ease our bug
triaging. 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 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). Typically, this
field will not change unless more information about the bug becomes
available from investigation or from customers. 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?
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 [email protected]
(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.
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?
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)
