Open Stack

Greetings,

At the last Nova meeting we started talking about some updates to the
Nova blueprint process for the Icehouse cycle.  I had hoped we could
talk about and finalize this in a Nova design summit session on "Nova
Project Structure and Process" [1], but I think we need to push forward
on finalizing this as soon as possible so that it doesn't block current
work being done.

Here is a first cut at the process.  Let me know what you think is
missing or should change.  I'll get the result of this thread posted on
the wiki.

1) Proposing a Blueprint

Proposing a blueprint for Nova is not much different than other
projects.  You should follow the instructions here:

    https://wiki.openstack.org/wiki/Blueprints

The particular important step that seems to be missed by most is:

"Once it is ready for PTL review, you should set:

Milestone: Which part of the release cycle you think your work will be
proposed for merging."

That is really important.  Due to the volume of Nova blueprints, it
probably will not be seen until you do this.

2) Blueprint Review Team

Ensuring blueprints get reviewed is one of the responsibilities of the
PTL.  However, due to the volume of Nova blueprints, it's not practical
for me to do it alone.  A team of people (nova-drivers) [2], a subset of
nova-core, will be doing blueprint reviews.

By having more people reviewing blueprints, we can do a more thorough
job and have a higher quality result.

Note that even though there is a nova-drivers team, *everyone* is
encouraged to participate in the review process by providing feedback on
the mailing list.

3) Blueprint Review Criteria

Here are some things that the team reviewing blueprints should look for:

The blueprint ...

 - is assigned to the person signing up to do the work

 - has been targeted to the milestone when the code is
   planned to be completed

 - is an appropriate feature for Nova.  This means it fits with the
   vision for Nova and OpenStack overall.  This is obviously very
   subjective, but the result should represent consensus.

 - includes enough detail to be able to complete an initial design
   review before approving the blueprint. In many cases, the design
   review may result in a discussion on the mailing list to work
   through details. A link to this discussion should be left in the
   whiteboard of the blueprint for reference.  This initial design
   review should be completed before the blueprint is approved.

 - includes information that describes the user impact (or lack of).
   Between the blueprint and text that comes with the DocImpact flag [3]
   in commits, the docs team should have *everything* they need to
   thoroughly document the feature.

Once the review has been complete, the blueprint should be marked as
approved and the priority should be set.  A set priority is how we know
from the blueprint list which ones have already been reviewed.

4) Blueprint Prioritization

I would like to do a better job of using priorities in Icehouse.  The
priority field services a couple of purposes:

  - helps reviewers prioritize their time

  - helps set expectations for the submitter for how reviewing this
    work stacks up against other things

In the last meeting we discussed an idea that I think is worth trying at
least for icehouse-1 to see if we like it or not.  The idea is that
*every* blueprint starts out at a Low priority, which means "best
effort, but no promises".  For a blueprint to get prioritized higher, it
should have 2 nova-core members signed up to review the resulting code.

If we do this, I suspect we may end up with more blueprints at Low, but
I also think we'll end up with a more realistic list of blueprints.  The
reality is if a feature doesn't have reviewers agreeing to do the
review, it really is in a "best effort, but no promises" situation.

5) Blueprint Fall Cleaning

Finally, it's about time we do some cleaning of the blueprint backlog.
There are a bunch not currently being worked on.  I propose that we
close out all blueprints not targeted at a release milestone by November
22 (2 weeks after the end of the design summit), with the exception of
anything just recently filed and still being drafted.


[1] http://summit.openstack.org/cfp/details/341
[2] https://launchpad.net/~nova-drivers/+members#active
[3]
http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/

-- 
Russell Bryant