Jump to: navigation, search

Difference between revisions of "WTP/Hotbug Policy"

< WTP
m (added related docs)
(added headers)
Line 2: Line 2:
 
This document is currently being reviewed. It is expected to be finalized around mid-September. This document is to clarify and replace the [http://www.eclipse.org/webtools/adopters/hot_bug_process.html previous hotbug process documentation].</div></div>
 
This document is currently being reviewed. It is expected to be finalized around mid-September. This document is to clarify and replace the [http://www.eclipse.org/webtools/adopters/hot_bug_process.html previous hotbug process documentation].</div></div>
  
 +
== Purpose ==
 
    
 
    
 
This document describes what a "hotbug" is, in WTP, and the process involved for submitting a hotbug request.
 
This document describes what a "hotbug" is, in WTP, and the process involved for submitting a hotbug request.
 
    
 
    
 +
== Hotbug request ==
 
A '''hotbug_request''' is simply a way for an adopter (with no committers on a project) to document what
 
A '''hotbug_request''' is simply a way for an adopter (with no committers on a project) to document what
 
they think the priority of a bug should be. It essentially means a "P1" from that adopters point of view.
 
they think the priority of a bug should be. It essentially means a "P1" from that adopters point of view.
Line 19: Line 21:
 
# Be clear on which release you want this bug to be fixed in, or "last workable" date, if requesting a patch. .  
 
# Be clear on which release you want this bug to be fixed in, or "last workable" date, if requesting a patch. .  
 
# Justify why this is a hotbug. Note that "our users don't like the bug" is not the type of reason that gets much attention. The motivation we are looking for to justify a P1-like priority is, basically, "this bug blocks our adoption of WTP" (explaining why, of course).
 
# Justify why this is a hotbug. Note that "our users don't like the bug" is not the type of reason that gets much attention. The motivation we are looking for to justify a P1-like priority is, basically, "this bug blocks our adoption of WTP" (explaining why, of course).
 +
 +
== Hotbug ==
 
    
 
    
 
If a hot bug request is accepted, the assignee should.  
 
If a hot bug request is accepted, the assignee should.  
Line 36: Line 40:
 
Also, one reason we provide this marking of "hotbug" is to help make the severity more
 
Also, one reason we provide this marking of "hotbug" is to help make the severity more
 
accurate. Without it, we often find people open bugs as "critical" to reflect "really important"
 
accurate. Without it, we often find people open bugs as "critical" to reflect "really important"
whereas severity should reflect the impact of a bug (for example, "critical" means "loss of data"). So, if a bug's severity is mismarked, then the originator might get a reputation for being shrill and and will receive less attention in the future. Thus, it is to your advantage to mark severity accurately and denote priority accurately.  
+
whereas severity should reflect the impact of a bug (for example, "critical" means "loss of data"). So, if a bug's severity is mismarked, then the originator might get a reputation for being shrill and and will receive less attention in the future. Thus, it is to your advantage to mark severity accurately and denote priority accurately. For guidance, see [[WTP/Conventions_of_bug_priority_and_severity| WTP Conventions of bug priority and severity]].
  
 
Adopters who request the '''hotbug''' designation should be prepared to submit a patch to fix the issue. The
 
Adopters who request the '''hotbug''' designation should be prepared to submit a patch to fix the issue. The

Revision as of 11:56, 8 September 2009

This document is currently being reviewed. It is expected to be finalized around mid-September. This document is to clarify and replace the previous hotbug process documentation.

Purpose

This document describes what a "hotbug" is, in WTP, and the process involved for submitting a hotbug request.

Hotbug request

A hotbug_request is simply a way for an adopter (with no committers on a project) to document what they think the priority of a bug should be. It essentially means a "P1" from that adopters point of view. (Note: committers do not need to use "hotbug" ... they can simply use "P1" as is their committer privilege.)

Any (non-committer) adopter can submit a hot bug request. If you are the originator of the bug (that is, you opened it), simply prefix the bugzilla abstract with [hotbug_request]. If you do not have authorization to change the abstract of a bug (that is, you didn't open it) then you will need to get a committer to mark it for you. In either case, you should include the following information in the bugzilla:

  1. Affiliation
  2. Be clear on which release you want this bug to be fixed in, or "last workable" date, if requesting a patch. .
  3. Justify why this is a hotbug. Note that "our users don't like the bug" is not the type of reason that gets much attention. The motivation we are looking for to justify a P1-like priority is, basically, "this bug blocks our adoption of WTP" (explaining why, of course).

Hotbug

If a hot bug request is accepted, the assignee should.

  1. Change the bugzilla prefix from [hotbug_request] to [hotbug].
  2. Set the milestone target field to reflect the requested release.

Note that "accepting" the hotbug simply means it is understood what the bug is, and it is agreed it fits the category of hotbug.

There is no commitment to fix it, just because its marked as hotbug.

So what is the effect of marking hotbug?

Hotbugs are reviewed in status meetings, along with "P1" bugs.

Also, one reason we provide this marking of "hotbug" is to help make the severity more accurate. Without it, we often find people open bugs as "critical" to reflect "really important" whereas severity should reflect the impact of a bug (for example, "critical" means "loss of data"). So, if a bug's severity is mismarked, then the originator might get a reputation for being shrill and and will receive less attention in the future. Thus, it is to your advantage to mark severity accurately and denote priority accurately. For guidance, see WTP Conventions of bug priority and severity.

Adopters who request the hotbug designation should be prepared to submit a patch to fix the issue. The owning team will definitely investigate the issue and in some cases be able to fix it by the time requested, but there is no commitment to do so. In many cases they may not be able fix it due to their own priorities and business needs. An attached patch always gets more attention and a high quality patch will always be accepted for a hotbug.

Related Documentation

WTP Bugs: Workflow and Conventions

WTP Conventions of bug priority and severity