Difference between revisions of "WTP/Hotfeature Policy"

From Eclipsepedia

< WTP
Jump to: navigation, search
(New page: == Purpose == This document describes what a "hotfeature" is, in WTP, and the process involved for submitting a hotfeature request. == hotfeature request == A '''hotfeature_request...)
 
(hotfeature request)
 
(One intermediate revision by one user not shown)
Line 11: Line 11:
  
  
Normal feature requests should continue to be handled through the normal bugzilla process.
+
Normal feature requests should continue to be handled through the normal enhancement bugzilla process.
  
  
Any bugzilla user can submit a hot feature request by simply prefix the bugzilla abstract with '''[hotfeature_request]'''. If you do not have
+
Any bugzilla user can submit a hot feature request by simply prefix the bugzilla abstract with '''[hotfeature_request]'''. If the requester 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 the requester will need to get a committer to mark it for you. In either case, you should include the following information in the bugzilla:
committer to mark it for you. In either case, you should include the following information in the
+
bugzilla:
+
  
 
# Justify why this is a hotfeature. The motivation and reasons you are looking for this high ranking feature, and be SPECIFIC!  Vague requests to "improve usability", or "improve performance" etc.. will be rejected.
 
# Justify why this is a hotfeature. The motivation and reasons you are looking for this high ranking feature, and be SPECIFIC!  Vague requests to "improve usability", or "improve performance" etc.. will be rejected.
 +
 +
The project lead will evaluate the hotfeature request, and will have 3 choices for action
 +
 +
# Disagree this is a valid hotfeature request, and will add comments for the reason being invalid or not differentiated from normal enhancement requests.
 +
# Agree this is a valid request, but ask for helpwanted (add this tag).  The project does not have existing resources for implementing feature.
 +
# Agree this is a valid request, and accept this officially as a hotfeature. (Covered in section below)
  
 
== hotfeature request voting and ranking ==
 
== hotfeature request voting and ranking ==
Line 32: Line 36:
 
# Change the bugzilla prefix from '''[hotfeature_request]''' to '''[hotfeature]'''.
 
# Change the bugzilla prefix from '''[hotfeature_request]''' to '''[hotfeature]'''.
 
# Set the milestone target field to reflect the requested release.  
 
# Set the milestone target field to reflect the requested release.  
#Add the word “plan” to the keywords field  
+
# Add the word “plan” to the keywords field  
  
Note that "accepting" the hot feature means it is not only understood what the feature request is, and it is agreed it fits
+
Note that "accepting" the hot feature means it is not only understood what the feature request is, and it is agreed it fits the category of '''hotfeature''', but also has agreed to allocate resources toward implementing this feature either from within the project or by identifying non-commiter contributors to the project.
The category of '''hotfeature''', but also has agreed to allocate resources toward implementing this feature either from within the project or by identifying non-commiter contributors to the project.
+
  
  

Latest revision as of 15:37, 26 September 2013

Contents

[edit] Purpose

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

[edit] hotfeature request

A hotfeature_request is simply a way for any adopter, user, or committer to document what they think a high priority feature should be. It essentially means a "P1" feature that currently doesn't have a designated owner.

Unlike a hotbug request, this is open to all users, and is intended to recognize high priority feature request for WTP as a top level project. These feature requests are made without any commitment from the existing projects members or backing organizations, and is intended to coordinate existing resources with the communities highest ranked requests.


Normal feature requests should continue to be handled through the normal enhancement bugzilla process.


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

  1. Justify why this is a hotfeature. The motivation and reasons you are looking for this high ranking feature, and be SPECIFIC! Vague requests to "improve usability", or "improve performance" etc.. will be rejected.

The project lead will evaluate the hotfeature request, and will have 3 choices for action

  1. Disagree this is a valid hotfeature request, and will add comments for the reason being invalid or not differentiated from normal enhancement requests.
  2. Agree this is a valid request, but ask for helpwanted (add this tag). The project does not have existing resources for implementing feature.
  3. Agree this is a valid request, and accept this officially as a hotfeature. (Covered in section below)

[edit] hotfeature request voting and ranking

The query that determines ranking order has not yet been created, but will rely on several factors including number of votes for the hotfeature, age of request, and possibly other factors not yet determined.

The hotfeature requests will not only be reviewed in status meetings, but will also be accessible from the WTP website.

[edit] hotfeature

If a hot feature request is accepted, it means a committer or possibly non-committer has agreed to accept the feature, and will include in the current release plan.

  1. Change the bugzilla prefix from [hotfeature_request] to [hotfeature].
  2. Set the milestone target field to reflect the requested release.
  3. Add the word “plan” to the keywords field

Note that "accepting" the hot feature means it is not only understood what the feature request is, and it is agreed it fits the category of hotfeature, but also has agreed to allocate resources toward implementing this feature either from within the project or by identifying non-commiter contributors to the project.


The main reason we provide this marking of "hotfeature" is to recognize the community driven features being included in the release plan.


[edit] Related Documentation

WTP Bugs: Workflow and Conventions

WTP Conventions of bug priority and severity