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/%[email protected]%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 [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
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".
