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 ==

== Purpose ==

Line 9:

Line 6:

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

# 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 ==

== Hotbug ==

Latest revision as of 13:32, 3 May 2011

Contents

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:

Affiliation (Company, other open source project, or adopting Eclipse Project)

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 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.

Change the bugzilla prefix from [hotbug_request] to [hotbug].

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.