On Fri, Mar 21, 2014 at 12:16 PM, Tim Bell <[email protected]> wrote: > > I am a strong advocate of the Blueprint-on-Blueprints process we discussed > in the operator mini-summit so that experienced cloud administrators can > give input before lots of code is written ( > https://etherpad.openstack.org/p/operators-feedback-mar14) but we need to > be aware that these people with real life experience of the impact of > changes on production clouds may not be working with gerrit day-to-day. > > There has been some excellent work by the documentation team in the past > year to make it easy for new contributors to work on improvements to the > documentation which also helps to introduce the tools/processes to the > novices. > > Can we find a way to keep the bar low for the review of blueprints while > at the same time making sure we engage the full community spectrum in the > future direction of OpenStack ? > > A lot of work has gone into making code review have a very low barrier to entry, the nova-specs uses the same process.
Going through the etherpad list I think we hit almost everything. 1. Operator Review of new features - Blueprint on Blueprints (aka BOB) - aim: apply a consistent operational view to all the things 1. Specific information put into blueprints 2. 3. http://git.openstack.org/cgit/openstack/nova-specs/tree/template.rst 1. Blueprint alerts Use gerrit to watch the nova-specs repo using https://review.openstack.org/#/settings/projects. This will let you get emails every time a new BP is posted 1. Operators in design summit sessions 2. 1. Not sure what the blockers are on this one. nova-specs doesn't directly relate to to the summit. 1. BluePrint Review Process (gerrit?) 2. 3. https://review.openstack.org/#/q/status:open+project:openstack/nova-specs,n,z Tim > > > -----Original Message----- > > From: Stefano Maffulli [mailto:[email protected]] > > Sent: 21 March 2014 19:55 > > To: [email protected] > > Subject: Re: [openstack-dev] [Nova] Updates to Juno blueprint review > process > > > > On 03/20/2014 03:50 PM, Jay Lau wrote: > > > It is better that we can have some diagram workflow just like > > > Gerrit_Workflow <https://wiki.openstack.org/wiki/Gerrit_Workflow> to > > > show the new process. > > > > Indeed, I think it would help. > > > > While I'm here, and for the records, I think that creating a new > workflow 'temporarily' only until we have Storyboard usable, is a > > *huge* mistake. It seems to me that you're ignoring or at least > underestimating the amount of *people* that will need to be > > retrained, the amount of documentation that need to be fixed/adjusted. > And the confusion that this will create on the 'long tail' > > developers. > > > > A change like this, done with a couple of announcements on a mailing > list and a few mentions on IRC is not enough to steer the ~400 > > developers who may be affected by this change. And then we'll have to > manage the change again when we switch to Storyboard. If I > > were you, I'd focus on getting storyboard ready to use asap, instead. > > > > There, I said it, and I'm now going back to my cave. > > > > .stef > > > > -- > > Ask and answer questions on https://ask.openstack.org > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
