Improvements to the blueprint management process

It is easy to oversubscribe ourselves during a release
cycle. We approve specs only to experience that we fail
to review consistently; code is posted last minute,
we get lost into chasing race conditions, the odd dependency
throws the gate under the bus, and the ever-present cosmetic
refactoring patch steers our attention from what matters,
which is *reviewing what we commit to deliver*.

In order to keep ourselves focused on the bigger picture,
this patch proposes/formalizes changes to the way we
register blueprints so that we can improve our ability
to better foresee what we'll deliver at the end of a
release.

We obviously can't predict the future or chain people
to a desk, but a regular pulse check of a well planned
task list should at least help mitigate the feeding frenzy
that usually happens closer to FF. That inevitably
leads to half-baked and buggy solutions.

Change-Id: Ia27b2a779204bf98c1dec2a30d00507de285f801

diff --git a/doc/source/policies/blueprints.rst b/doc/source/policies/blueprints.rst
index 72a6a4d849b3d6b321b414a3297bf440436a1f88..30a8c07d1217dfc8a67942fbcf098fc03cec8d09 100644 (file)
--- a/doc/source/policies/blueprints.rst
+++ b/doc/source/policies/blueprints.rst
@@ -2,16 +2,16 @@ Blueprints and Specs
 ====================
 
 The Neutron team uses the `neutron-specs
-<http://git.openstack.org/cgit/openstack/neutron-specs>`_ repository for it's
+<http://git.openstack.org/cgit/openstack/neutron-specs>`_ repository for its
 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.
 
-The Neutron team does not enforce deadlines for specs and blueprints. These
-can be submitted throughout the release cycle. The drivers team will review
-this on a regular basis throughout the release, and based on the load for the
-milestones, will assign these into milestones or move them to the backlog
-for selection into a future release.
+The Neutron team does not enforce deadlines for specs. These can be submitted
+throughout the release cycle. The drivers team will review this on a regular
+basis throughout the release, and based on the load for the milestones, will
+assign these into milestones or move them to the backlog for selection into
+a future release.
 
 Please note that we use a `template
 <http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/template.rst>`_
@@ -19,22 +19,6 @@ for spec submissions. It is not required to fill out all sections in the
 template. Review of the spec may require filling in information left out by
 the submitter.
 
-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 work flow 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.
-
 Neutron Request for Feature Enhancements
 ----------------------------------------
 
@@ -79,8 +63,57 @@ The workflow for the life an RFE in Launchpad is as follows:
   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)
-  and consistency accross the various fields required during the blueprint
-  registration process (Approver, Drafter, etc.).
+  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:
+
+  * 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
+    go-to contributor, if more people are involved. Typically this is
+    the RFE submitter, but not necessarily.
+  * Approver: a member of the Neutron team who can commit enough time
+    during the ongoing release cycle to ensure that code posted for review
+    does not languish, and that all aspects of the feature development are
+    taken care of (client, server changes and/or support from other projects
+    if needed - tempest, nova, openstack-infra, devstack, etc.), as well as
+    comprehensive testing.
+    This is typically a core member who has enough experience with what it
+    takes to get code merged, but other resources amongst the wider team can
+    also be identified. Approvers are volunteers who show a specific interest
+    in the blueprint specification, and have enough insight in the area of
+    work so that they can make effective code reviews and provide design
+    feedback. An approver will not work in isolation, as he/she can and will
+    reach out for help to get the job done; however he/she is the main
+    point of contact with the following responsibilities:
+
+  * Pair up with the drafter/assignee in order to help skip development
+    blockers.
+  * Review patches associated with the blueprint: approver and assignee
+    should touch base regularly and ping each other when new code is
+    available for review, or if review feedback goes unaddressed.
+  * Reach out to other reviewers for feedback in areas that may step
+    out of the zone of her/his confidence.
+  * Escalate issues, and raise warnings to the release team/PTL if the
+    effort shows slow progress. Approver and assignee are key parts to land
+    a blueprint: should the approver and/or assignee be unable to continue
+    the committment during the release cycle, it is the Approver's
+    responsibility to reach out the release team/PTL so that replacements
+    can be identified.
+  * Provide a status update during the Neutron IRC meeting, if required.
+
+  Approver `assignments <https://blueprints.launchpad.net/neutron/+assignments>`_
+  must be carefully identified to ensure that no-one overcommits. A
+  Neutron contributor develops code himself/herself, and if he/she is an
+  approver of more than a couple of blueprints in a single cycle/milestone
+  (depending on the complexity of the spec), it may mean that he/she is
+  clearly oversubscribed.
+  The Neutron team will review the status of blueprints targeted for the
+  milestone during their weekly meeting to ensure a smooth progression of
+  the work planned. Blueprints for which resources cannot be identified
+  will have to be deferred.
+
 * In either case (a spec being required or not), once discussion has happened
   the bug will get an assignee, priority and milestone.
 * At this point, the RFE is 'approved', and its tag will move from 'rfe' to
@@ -162,3 +195,20 @@ questions:
 
 Once you are happy with what you wrote, add 'rfe' as tag, and submit. Do not
 worry, we are here to help you get it right! Happy hacking.
+
+
+Missing your target
+-------------------
+
+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 work flow 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.