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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev