Open Stack

> On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
> > On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery <mestery at mestery.com>
> wrote:
> > > > I really like this idea, as Michael and others alluded to in
> > > > above, we
> > > are
> > > > attempting to set cycle goals for Kilo in Nova. but I think it is
> > > > worth doing for all of OpenStack. We would like to make a list of
> > > > key goals
> > > before
> > > > the summit so that we can plan our summit sessions around the
> > > > goals. On a really high level one way to look at this is, in Kilo
> > > > we need to pay down our technical debt.
> > > >
> > > > The slots/runway idea is somewhat separate from defining key cycle
> > > goals; we
> > > > can be approve blueprints based on key cycle goals without doing slots.
> > >  But
> > > > with so many concurrent blueprints up for review at any given
> > > > time, the review teams are doing a lot of multitasking and humans
> > > > are not very
> > > good at
> > > > multitasking. Hopefully slots can help address this issue, and
> > > > hopefully allow us to actually merge more blueprints in a given cycle.
> > > >
> > > I'm not 100% sold on what the slots idea buys us. What I've seen
> > > this cycle in Neutron is that we have a LOT of BPs proposed. We
> > > approve them after review. And then we hit one of two issues: Slow
> > > review cycles, and slow code turnaround issues. I don't think slots
> > > would help this, and in fact may cause more issues. If we approve a
> > > BP and give it a slot for which the eventual result is slow review
> > > and/or code review turnaround, we're right back where we started.
> > > Even worse, we may have not picked a BP for which the code submitter
> > > would have turned around reviews faster. So we've now doubly hurt
> > > ourselves. I have no idea how to solve this issue, but by over
> > > subscribing the slots (e.g. over approving), we allow for the
> > > submissions with faster turnaround a chance to merge quicker. With
> > > slots, we've removed this capability by limiting what is even
> > > allowed to be considered for review.
> > >
> >
> > Slow review: by limiting the number of blueprints up we hope to focus
> > our efforts on fewer concurrent things slow code turn around: when a
> > blueprint is given a slot (runway) we will first make sure the
> > author/owner is available for fast code turnaround.
> >
> > If a blueprint review stalls out (slow code turnaround, stalemate in
> > review discussions etc.) we will take the slot and give it to another
> blueprint.
>
>  On Wed , Aug 13, 2014 Daniel Berrange wrote:
> This idea of fixed slots is not really very appealing to me. It sounds like we're
> adding a significant amount of buerocratic overhead to our development
> process that is going to make us increasingly inefficient.
> I don't want to waste time wating for a stalled blueprint to time out before
> we give the slot to another blueprint. On any given day when I have spare
> review time available I'll just review anything that is up and waiting for
> review. If we can set a priority for the things up for review that is great since I
> can look at those first, but the idea of having fixed slots for things we should
> review does not do anything to help my review efficiency IMHO.
> 
> I also thing it will kill our flexibility in approving & dealing with changes that
> are not strategically important, but none the less go through our
> blueprint/specs process. There have been a bunch of things I've dealt with
> that are not strategic, but have low overhead to code and review and easily
> dealt with in the slack time between looking at the high priority reviews. It
> sounds like we're going to loose our flexibility to pull in stuff like this if it only
> gets a chance when strategically imporatant stuff is not occupying a slot
> 
> Regards,
> Daniel
> --

I am also not in favour of this fixed slots approach because of the potential lack of flexibility and overhead that could be introduced in the process. 

There has been lots of great mailing list traffic over the last month about blueprint spec freeze deadlines, exceptions, review priorities, inter-project dependencies on approvals, etc. We had a brief discussion in the NFV working group [1] and this is a really creative thread on how we can address some of the challenges in getting a proposal from concept through to blueprint acceptance and code integration.  I think some of the difficulty on converging on a proposal in this thread stems from the number of problem statements that are being addressed simultaneously. 

In no particular order and not an exhaustive list, here are some of the challenges that I've seen mentioned on this thread and others so far:
- There is an imbalance between strategic and tactical submissions.
- There is growing technical debt and lack of clarity on how that should be dealt with.
- There is inconsistency, and in some cases a lack of clarity, in how the entire lifecycle of a new proposal is dealt with within projects and across projects. E.g. What the various checkpoints on the lifecycle of a new proposal mean. What does having a blueprint accepted really imply and even more importantly what does it not imply?
- There is a difficulty in predicting the time required for the various stages in the lifecycle of new proposals. E.g. No SLA on when blueprint or code reviews may happen, and negative feedback (which could be completely valid) can come in just before a deadline giving the submitter little chance to address comments in time for the deadline.
- There is a lack of clarity and consistency in how proposals that are progressing slowly should be dealt with from both submitter and reviewer/approver perspectives.
- There is a lack of clarity on how best to progress cross-project proposals that have interdependencies that need to land in the same release.
- There is a lack of clarity and consistency on how to appeal decisions.

There are several great wikis that aim to provide guidance on how to navigate the blueprint process and general guides on community participation [2], [3], [4], [5], etc. Ultimately I think these need to be harmonized to reflect any new process that may be defined. 

One proposal in this thread that I would really welcome was from Rochelle Grober who wrote:
"Each BP and each spec should have at least one core that "owns" it.  They will watch it more closely and at least be willing to answer questions, discuss designs, or find another developer who will shepherd the assigned developer through the process (if they need it)". 
Assuming a core is assigned/volunteers, then having them mentor new proposals would be a very effective way to help contributors navigate OpenStack. I would also propose to extend this with a type of honour system so that when a contributor gets this type of help on a proposal, they subsequently volunteer to mentor two more proposals, at a minimum from a process perspective. This should help reduce the load on the cores and contribute something back to the community.

Regards,
Adrian

[1] http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-30-14.00.log.html
[2] https://wiki.openstack.org/wiki/Blueprints 
[3] https://wiki.openstack.org/wiki/NeutronReviews 
[4] http://bit.ly/navigating-openstack-community 
[5] https://wiki.openstack.org/wiki/Juno_Release_Schedule
---

--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.