Elaborate how priorities are assigned to blueprints

Prioritizing is hard, and prioritizing in open source, let
alone Openstack, is even harder.

For this reason, this proposal attempts to clarify what priority
mean, how we prioritize in Neutron, in a way that's objective,
consistent, and reproducible. To start with, and make things slightly
simpler, we reduce the number of priority buckets we can choose from
to two: High and Low.

The way priorities are assigned is then based on a set of clearly defined
criteria: high priority work items are items that all core folks
collectively should care about because any failure in achieving tangible
result make them look bad. Low work items are great to have, but if they
slipped, it would be a shame but not the end of the world.

Keep on reading to learn more.

Change-Id: I0f4ba622eb3d8e02b0c3204967fb8eae22db09c8

diff --git a/doc/source/policies/blueprints.rst b/doc/source/policies/blueprints.rst
index 75a01404cb2a503337d0c9edcbc57d9a0179fd9b..219557f6dd6848f484e3ade21293280e9cc2bfdf 100644 (file)
--- a/doc/source/policies/blueprints.rst
+++ b/doc/source/policies/blueprints.rst
@@ -62,23 +62,48 @@ 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 assignee, importance, or milestone is
-  set at this time.
+  be moved into the "Confirmed" state. No assignee, or milestone is set at this
+  time. The importance will be set to 'Wishlist' to signal the fact that the
+  report is indeed a feature or enhancement and there is no severity associated
+  to it.
 * 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
-  to file a spec in neutron-specs to elaborate on the feature request.
+  to file a spec in neutron-specs to elaborate on the feature request, in case
+  the RFE requires extra scrutiny, more design discussion, etc.
 * The PTL will work with the Lieutenant for the area being identified by the
   RFE to evaluate resources against the current workload.
 * If a spec is necessary, a member of the Neutron release team will register
   a matching Launchpad blueprint to be used for milestone tracking purposes,
   and as a landing page for the spec document, as available on `specs.o.o. <http://specs.openstack.org/openstack/neutron-specs/>`_.
   The blueprint will then be linked to the original RFE bug report. This
-  step will ensure higher visibility of the RFE over smaller RFEs (in scope)
+  step will ensure higher visibility of the RFE over the other RFEs
   and consistency across the various fields required during the blueprint
   registration process (Approver, Drafter, etc.). More precisely, the
   blueprint submitter will work with the RFE submitter to identify the
   following:
 
+  * Priority: there will be only two priorities to choose from, High and Low.
+    It is worth noting that priority is not to be confused with `importance <https://wiki.openstack.org/wiki/Bugs#Importance>`_,
+    which is a property of Launchpad Bugs. Priority gives an indication of
+    how promptly a work item should be tackled to allow it to complete. High
+    priority is to be chosen for work items that must make substantial
+    progress in the span of the targeted release, and deal with the
+    following aspects:
+
+    * OpenStack cross-project interaction and interoperability issues;
+    * Issues that affect the existing system's usability;
+    * Stability and testability of the platform;
+    * Risky implementations that may require complex and/or pervasive
+      changes to API and the logical model;
+
+    Low priority is to be chosen for everything else. RFEs without an associated
+    blueprint are effectively equivalent to low priority items. Bear in mind that,
+    even though staffing should take priorities into account (i.e. by giving more
+    resources to high priority items over low priority ones), the open source
+    reality is that they can both proceed at their own pace and low priority items
+    can indeed complete faster than high priority ones, even though they are
+    given fewer resources.
+
   * Drafter: who is going to submit and iterate on the spec proposal; he/she
     may be the RFE submitter.
   * Assignee: who is going to develop the bulk of the code, or the