Open Stack

On Wed, Oct 23, 2013 at 4:33 PM, Russell Bryant <rbryant at redhat.com> wrote:

> 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.
>
>
++ to the entire process, two comments though.

* It would be great to get this into a wiki for future reference
* We shouldn't merge patches with un-approved blueprints. And when that
happens having a wiki page to point to would be great.


>
> [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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131024/a24c9375/attachment.html>