Jump to: navigation, search

Difference between revisions of "WTP Bugs, Workflow and Conventions"

(Workflow: added new general target field description)
(added section on verification and closing of bugs)
Line 21: Line 21:
 
The target field should be assigned once the owner is relatively confident the fix will actually appear in that milestone. In other words, its not for long term planning, but more for short term planning and historical checking of "what's fixed" in a particular milestone.  
 
The target field should be assigned once the owner is relatively confident the fix will actually appear in that milestone. In other words, its not for long term planning, but more for short term planning and historical checking of "what's fixed" in a particular milestone.  
  
The target field can, though, be used for one form of "mid-range" planning. Our usual targets contain the release and the milestone, such as "2.0 M3". Those are the specific targets that should not be set until it is pretty clear the fix is going in that milestone. But, there is another target that represents the whole release "2.0". This can be used for "mis-range" planning, in that committers for a component, if it helps their planning, can assign a bug or feature request to "2.0", which would mean simply it is their <b>plan</p> to fix that release. It is not a "committed" item, but helps some teams arrange work-flow, assignments, expectations, etc. And, just because the target feild is unassigned does not mean it will not be fixed in the next release ... just maybe hasn't caught anyone's attention yet, or its "unknown" how important it is, pending more investigation. It would be wrong for committers to just blindly assign all unspecified targets to the "2.0" target. It should only be for things which are explicitly being planned for. By the end of the release, there should be no general ("2.0") targets left, either having been delivered in a particular milestone, or, explicitly decided it could not be done after all and changed to 'unspecified' until the next planning cycle.  
+
The target field can, though, be used for one form of "mid-range" planning. Our usual targets contain the release and the milestone, such as "2.0 M3". Those are the specific targets that should not be set until it is pretty clear the fix is going in that milestone. But, there is another target that represents the whole release "2.0". This can be used for "midrange" planning, in that committers for a component, if it helps their planning, can assign a bug or feature request to "2.0", which would mean simply it is their <b>plan</p> to fix that release. It is not a "committed" item, but helps some teams arrange work-flow, assignments, expectations, etc. And, just because the target field is unassigned does not mean it will not be fixed in the next release ... just maybe hasn't caught anyone's attention yet, or its "unknown" how important it is, pending more investigation. It would be wrong for committers to just blindly assign all unspecified targets to the "2.0" target. It should only be for things which are explicitly being planned for. By the end of the release, there should be no general ("2.0") targets left, either having been delivered in a particular milestone, or, explicitly decided it could not be done after all and changed to 'unspecified' until the next planning cycle.  
  
 
Note: the 'version' field is considered too ambiguous and used too inconsistently to be of much value ... but, there is a pattern that is supposed to be followed. When someone reports a bug, they are supposed to mark the version as the version they found the bug in, as close as possible (but, they usually need to give the exact build id of the version they were using, to be meaningful). Then, when fixed, the bug owner should change the version to the version the bug was fixed in).
 
Note: the 'version' field is considered too ambiguous and used too inconsistently to be of much value ... but, there is a pattern that is supposed to be followed. When someone reports a bug, they are supposed to mark the version as the version they found the bug in, as close as possible (but, they usually need to give the exact build id of the version they were using, to be meaningful). Then, when fixed, the bug owner should change the version to the version the bug was fixed in).
Line 36: Line 36:
  
 
;[API Request]: this marks an enhancement request where the originator is letting us know that to accomplish some function/extension, they need to use some of our internal non-API methods.
 
;[API Request]: this marks an enhancement request where the originator is letting us know that to accomplish some function/extension, they need to use some of our internal non-API methods.
 +
 +
;[api]: this marks a bug in the "API nature" of an implementation or its documentation. It may signify, as examples, cases were an implementation does not meet spec, or a spec is not unambiguous.
 +
 +
== The meaning and methods of verification ==
 +
 +
;FIXED to VERIFIED: The ideal, preferred workflow is for the originator to verify a bug is fixed shortly after its introduced into a build.
 +
:For old bugs, opened on previous releases, verification normally means "works on current release" unless otherwise noted (that is the previous release may not be fixed and may never be fixed ... unless otherwise noted).
 +
:The component or project leads have the discretion to mark a bug as "closed" if it has been in the fixed state for a very long time (such as 6 months) so it can pretty clearly be assumed fixed. Naturally, the originator can re-open (or, open a new bug).
 +
 +
;DUP to VERIFIED: verifying a "duped" bug means the originator is simply agreeing that its a valid dup ... not that its necessarily fixed. The originator should be added automatically to the CC list of the dup, and they are welcome to verify that once its marked as fixed.
 +
 +
;INVALID or WORKSFORME to VERIFIED: the originator is simply signifying they see the point and agree. If the originator does not agree or does not see the point, typically some polite discussion can be carried on in the bugzilla entry without necessarily re-opening.
 +
 +
;LATER or REMIND: while these are (unfortunately) sitting in a "resolved" state ... they are just resolved temporarily and it is not meaningful to mark them as "verified". The component or project leads have the discretion to mark a 'remind' bug as "closed" if it has been in the 'remind' state for a very long time (such as 6 months) so it can pretty clearly be assumed no answer is coming and must not still be a problem. Naturally, the originator can re-open (or, open a new bug).
 +
 +
VERIFIED to CLOSED: the typical workflow is for the component lead (or project lead, or QA Contact) to move a bug from a 'verified' state to the 'closed' state and simply signifies they agree the bug has gone through a valid workflow, or that the bug entry is no longer helpful, constructive, or needed.

Revision as of 21:43, 22 September 2006

Introduction and Purpose of this document

Our WTP Bugs are tracked in the Eclipse bugzilla system.

There is a main "Web Tools" classification category, with, currently, three subclassifications (called "Products" in bugzilla): Web Tools proper, for released components; and others for subprojects or components that are incubating (currently AFT, and Java Server Faces, and soon JPA).

The purpose of this document is not to repeat or contradict the normal bugzilla help documentation, but simply to supplement it, and be explicit about conventions we in WTP use that are not part of the bugzilla system per se.

Workflow

The following are a guide to the day to day work that component leads and bug owners follow.

When a bug is first reported, it is put in the "inbox" of the component that was specified.

Relatively soon after that (e.g. within one week) component owners should do initial triage, and specify a specific person to own the bug. This initial triage is just an acknowledgement that it appears to be a valid report, and that it is in the right component. Things like priority might be assigned at this time, but, that can also be done later.

Based on severity, priority, and the bug owner's time constraints :( the owner will further triage or investigate the bug, ask clarifying questions, try to reproduce, etc.

Once someone starts actively working on a bug, to produce a fix, they should put the bug in the "assigned" state. That way, other committers know they should not also work on it. If a bug is not in an assigned state, other committers are free to assume ownership of a bug, if, for example, it is related to other bugs they are working on, or, they happen to know about that area of code due to working on it before, etc.

The target field should be assigned once the owner is relatively confident the fix will actually appear in that milestone. In other words, its not for long term planning, but more for short term planning and historical checking of "what's fixed" in a particular milestone.

The target field can, though, be used for one form of "mid-range" planning. Our usual targets contain the release and the milestone, such as "2.0 M3". Those are the specific targets that should not be set until it is pretty clear the fix is going in that milestone. But, there is another target that represents the whole release "2.0". This can be used for "midrange" planning, in that committers for a component, if it helps their planning, can assign a bug or feature request to "2.0", which would mean simply it is their plan</p> to fix that release. It is not a "committed" item, but helps some teams arrange work-flow, assignments, expectations, etc. And, just because the target field is unassigned does not mean it will not be fixed in the next release ... just maybe hasn't caught anyone's attention yet, or its "unknown" how important it is, pending more investigation. It would be wrong for committers to just blindly assign all unspecified targets to the "2.0" target. It should only be for things which are explicitly being planned for. By the end of the release, there should be no general ("2.0") targets left, either having been delivered in a particular milestone, or, explicitly decided it could not be done after all and changed to 'unspecified' until the next planning cycle.

Note: the 'version' field is considered too ambiguous and used too inconsistently to be of much value ... but, there is a pattern that is supposed to be followed. When someone reports a bug, they are supposed to mark the version as the version they found the bug in, as close as possible (but, they usually need to give the exact build id of the version they were using, to be meaningful). Then, when fixed, the bug owner should change the version to the version the bug was fixed in).

Conventions of embellishments

<b>Status Whiteboard: This is pretty much for each component to use as they see fit ... usually marking short term notes of "needs review", etc., pretty much characterized as communication with other team members.

Keywords: committers should set these "built in" keywords accurately: (e.g. 'api', 'performance'), and if there is a built in keyword, there is no need to be redundant and specify the same thing as a summary keyword.

Summary keywords: These are the words or phrases contained in square brackets in the bug's summary line. Sometimes, components will use their own conventions to allow "sub categories" of bugs for their own book keeping (for example, "[project creation]"). But, the following list are project-wide conventions. Its not necessarily exhaustive, but we'll try to keep this list accurate. Note: in the event more than one summary keyword is desired, they should each be contained in square brackets, such as "[hotbug][project creation]". (Their order not being significant, and case is not significant).

[internal api]
this marks a bug report where our WTP code calls a non-api method of a prerequisite class.
[API Request]
this marks an enhancement request where the originator is letting us know that to accomplish some function/extension, they need to use some of our internal non-API methods.
[api]
this marks a bug in the "API nature" of an implementation or its documentation. It may signify, as examples, cases were an implementation does not meet spec, or a spec is not unambiguous.

The meaning and methods of verification

FIXED to VERIFIED
The ideal, preferred workflow is for the originator to verify a bug is fixed shortly after its introduced into a build.
For old bugs, opened on previous releases, verification normally means "works on current release" unless otherwise noted (that is the previous release may not be fixed and may never be fixed ... unless otherwise noted).
The component or project leads have the discretion to mark a bug as "closed" if it has been in the fixed state for a very long time (such as 6 months) so it can pretty clearly be assumed fixed. Naturally, the originator can re-open (or, open a new bug).
DUP to VERIFIED
verifying a "duped" bug means the originator is simply agreeing that its a valid dup ... not that its necessarily fixed. The originator should be added automatically to the CC list of the dup, and they are welcome to verify that once its marked as fixed.
INVALID or WORKSFORME to VERIFIED
the originator is simply signifying they see the point and agree. If the originator does not agree or does not see the point, typically some polite discussion can be carried on in the bugzilla entry without necessarily re-opening.
LATER or REMIND
while these are (unfortunately) sitting in a "resolved" state ... they are just resolved temporarily and it is not meaningful to mark them as "verified". The component or project leads have the discretion to mark a 'remind' bug as "closed" if it has been in the 'remind' state for a very long time (such as 6 months) so it can pretty clearly be assumed no answer is coming and must not still be a problem. Naturally, the originator can re-open (or, open a new bug).

VERIFIED to CLOSED: the typical workflow is for the component lead (or project lead, or QA Contact) to move a bug from a 'verified' state to the 'closed' state and simply signifies they agree the bug has gone through a valid workflow, or that the bug entry is no longer helpful, constructive, or needed.