Jump to: navigation, search

Difference between revisions of "WTP/Hotbug Policy"

< WTP
(update hotbug process)
 
m (Hotbug request)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
<div style="border: thin solid black; background-color: #F4FFF4; margin: 3px"><div style="margin: 4px">
+
== Purpose ==
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 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.
(Note: committers do not need to use "hotbug" ... they can simply use "P1" as is their committer
+
Committers do not need to use "hotbug" ... they can simply use "P1" as is their committer
privilege.)
+
privilege.
  
Any (non-committer) adopter can submit a hot bug request. If you are the originator of the bug (that is,
+
Any (non-committer) adopter can submit a hot bug request; where adopters means some other Eclipse project, some other open source project, or some product adopter. 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
 
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
 
authorization to change the abstract of a bug (that is, you didn't open it) then you will need to get a
Line 16: Line 15:
 
bugzilla:
 
bugzilla:
  
# Affiliation  
+
# Affiliation (Company, other open source project, or adopting Eclipse Project)
# 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 your patched applied, or the "last workable" date, if need before a literally release (e.g. for testing, adoption).  
# 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 hotbug priority is, something similar to, "this bug blocks our adoption of WTP because ... " (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 37:
 
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
Line 42: Line 43:
 
requested, but there is no commitment to do so. In many cases they may not be able fix it due to their
 
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.
 
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%2C_Workflow_and_Conventions| WTP Bugs: Workflow and Conventions]]
 +
 +
[[WTP/Conventions_of_bug_priority_and_severity| WTP Conventions of bug priority and severity]]
  
 
[[Category:Eclipse Web Tools Platform Project]][[Category:Process and Policies| ]]
 
[[Category:Eclipse Web Tools Platform Project]][[Category:Process and Policies| ]]

Latest revision as of 13:32, 3 May 2011

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. 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; where adopters means some other Eclipse project, some other open source project, or some product adopter. 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 (Company, other open source project, or adopting Eclipse Project)
  2. Be clear on which release you want this bug to be fixed in or your patched applied, or the "last workable" date, if need before a literally release (e.g. for testing, adoption).
  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 hotbug priority is, something similar to, "this bug blocks our adoption of WTP because ... " (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