Clarify that RFE bug reports should not have an importance set

Filling the Importance field [1] with anything other than Wishlist for RFE bug reports
is wrong. People confuse priority with Severity (which is what the importance field is
about), and that can cause us some grief.

Therefore let's state clearly that from now on, RFE bug reports will be marked 'Wishlist'
only.

[1] https://wiki.openstack.org/wiki/Bugs#Importance

Change-Id: I4f12301e5d6b9b754efd456f0fb9da4e64555373

diff --git a/doc/source/policies/blueprints.rst b/doc/source/policies/blueprints.rst
index a777ca8e6a2268a34ea461c066d58a31a4349739..75a01404cb2a503337d0c9edcbc57d9a0179fd9b 100644 (file)
--- a/doc/source/policies/blueprints.rst
+++ b/doc/source/policies/blueprints.rst
@@ -62,7 +62,7 @@ The workflow for the life an RFE in Launchpad is as follows:
 
 * The bug is submitted and will by default land in the "New" state.
 * As soon as a member of the neutron-drivers team acknowledges the bug, it will
-  be moved into the "Confirmed" state. No priority, assignee, or milestone is
+  be moved into the "Confirmed" state. No assignee, importance, or milestone is
   set at this time.
 * The bug goes into the "Triaged" state while the discussion is ongoing.
 * The neutron-drivers team will evaluate the RFE and may advise the submitter
@@ -152,6 +152,9 @@ In summary:
 
 Once the triaging (discussion is complete) and the RFE is approved, the tag goes from 'rfe'
 to 'rfe-approved', and at this point the bug report goes through the usual state transition.
+Note, that the importance will be set to 'wishlist', to reflect the fact that the bug report
+is indeed not a bug, but a new feature or enhancement. This will also help have RFEs that are
+not followed up by a blueprint standout in the Launchpad `milestone dashboards <https://launchpad.net/neutron/+milestones>`_.
 
 The drivers team will be discussing the following bug reports during their IRC meeting: