On Wed, Oct 23, 2013 at 4:33 PM, Russell Bryant <rbry...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev