Jump to: navigation, search

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

m
(Workflow: added new general target field description)
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.  
  
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).  
+
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.
 +
 
 +
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 ==  
 
== Conventions of embellishments ==  

Revision as of 02:29, 25 August 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 "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 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.

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.