Add language around re-proposing specs for new releases

Attempt to provide guidance over how we handle specs which do not make
a release and want to be re-proposed into the next release.

Change-Id: I3820438e81fced0630c471f1e240174e63bbf062

diff --git a/doc/source/policies/blueprints.rst b/doc/source/policies/blueprints.rst
index 3de00780392d0497e65dff95601a3dff06c5c888..50ab9e7668254208b0aa6d412ed5d923e2cc24fa 100644 (file)
--- a/doc/source/policies/blueprints.rst
+++ b/doc/source/policies/blueprints.rst
@@ -6,5 +6,14 @@ repository for it's specification reviews. Detailed information can be found
 `here <https://wiki.openstack.org/wiki/Blueprints#Neutron>`_. Please also find additional
 information in the reviews.rst file.
 
-Please note that at the start of each cycle, any BP/spec which did not make it in the release
-will need to be resubmitted and approved for the next cycle.
+Neutron BP and Spec Notes
+-------------------------
+
+There are occasions when a spec will be approved and the code will not land in the cycle it was targeted at. For these cases,
+the workflow to get the spec into the next release is as follows:
+
+* The PTL will create a <release>-backlog directory during the RC window and move all specs which didn't make the <release> there.
+* Anyone can propose a patch to neutron-specs which moves a spec from the previous release into the new release directory.
+
+The specs which are moved in this way can be fast-tracked into the next release. Please note that it is required to re-propose
+the spec for the new release however.