Flesh out the new RFE process and set deadlines for it's use

The new RFE process is great in concept, but as was discovered in the
first neutron-drivers meeting where we discussed these, there exist
some rough edges. Specifically around deadlines and the conversion to
using RFEs, the gray area was very obvious. This patch attempts to put
a stake in the ground for when we transition fully to this new model,
including distinct timelines.

Given that we will need to work with people during the transition,
what is proposed is a way to let us do that while not blocking existing
specs and work.

Change-Id: Ife50f65caf4b13405ad60dd4be3d347aa31ef3a7

diff --git a/doc/source/policies/blueprints.rst b/doc/source/policies/blueprints.rst
index a272fd2794b6acf4658f36bfd31094f14861f90c..c8b5c9e611574aebd21cf07e5590f8d58fa12401 100644 (file)
--- a/doc/source/policies/blueprints.rst
+++ b/doc/source/policies/blueprints.rst
@@ -51,10 +51,52 @@ list.
 
 RFEs can be submitted by anyone and by having the community vote on them in
 Launchpad, we can gauge interest in features. The drivers team will evaluate
-these on a weekly basis along with the specs.
+these on a weekly basis along with the specs. RFEs will be evaluated in the
+current cycle against existing project priorities and available resources.
 
 The process for moving work from RFEs into the code involves someone assigning
-themselves the RFE bug and filing a matching spec in the neutron-specs
-repository. The spec will then be reviewed by the community and approved by
-the drivers team before landing in a release. This is the same process as
-before RFFs existed in Neutron.
+themselves the RFE bug and filing a matching spec using the slimmed down
+template in the neutron-specs repository. The spec will then be reviewed by the
+community and approved by the drivers team before landing in a release. This is
+the same process as before RFEs existed in Neutron.
+
+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
+  set at this time.
+* The bug goes into the "Triaged" state once a discussion around the RFE has
+  taken place.
+* 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.
+* The PTL will work with the Lieutenant for the area being identified by the
+  RFE to evaluate resources against the current workload.
+* In either case (a spec being required or not), once discussion has happened
+  the bug will get an assignee, priority and milestone.
+* Once a patchset targeting the bug is submitted the bug will move into the
+  "In Progress" state.
+* When all patches targeting the bug are merged or abandoned, the bug will be
+  moved to the "Completed" state.
+
+Cutover to RFEs From Pure Specs
+-------------------------------
+
+Prior to the Liberty release, Neutron relied purely on a waterfall model for
+handling specs. During Liberty, the goal is to move to the above referenced
+RFE process. This will allow for the separation of the "What" from the "How",
+and ideally allow for better scheduling of work by the PTL and Lieutenants.
+However, given the fact we have a backlog of specs already and new specs
+proposed, we need a path forward to not create extra work for everyone.
+
+For Liberty-1, we will allow the old specs to be reviewed as-is. The drivers
+team will ensure all specs submitted a week before the Liberty-1 deadline are
+given a review and approved or rejected. After Liberty-1, people will not be
+required to convert their specs over to RFE bugs during Liberty-1. Once
+Liberty-1 passes, all old specs will be moved to a "liberty-backlog" directory
+and anything new will follow the new RFE process fully.
+
+RFE Submission Guidelines
+-------------------------
+
+#TODO(marun)