Skip to main content
Jump to: navigation, search

WTP/Hotbug Policy

Revision as of 12:51, 8 September 2009 by David (Talk | contribs) (added related docs)

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.

This document describes what a "hotbug" is, in WTP, and the process involved for submitting a 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).

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.

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

Back to the top