Open Stack

Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400:
> On 17/09/18 3:06 PM, Jay Pipes wrote:
> > On 09/17/2018 01:31 PM, Doug Hellmann wrote:
> >> New Project Application Process
> >> ===============================
> >>
> >> We wrapped up Sunday with a discussion of of our process for reviewing
> >> new project applications. Zane and Chris in particular felt the
> >> process for Adjutant was too painful for the project team because
> >> there was no way to know how long discussions might go on and now
> >> way for them to anticipate some of the issues they encountered.
> >>
> >> We talked about formalizing a "coach" position to have someone from
> >> the TC (or broader community) work with the team to prepare their
> >> application with sufficient detail, seek feedback before voting
> >> starts, etc.
> >>
> >> We also talked about adding a time limit to the process, so that
> >> teams at least have a rejection with feedback in a reasonable amount
> >> of time.  Some of the less contentious discussions have averaged
> >> from 1-4 months with a few more contentious cases taking as long
> >> as 10 months. We did not settle on a time frame during the meeting,
> >> so I expect this to be a topic for us to work out during the next
> >> term.
> > 
> > So, to summarize... the TC is back to almost exactly the same point it 
> > was at right before the Project Structure Reform happened in 2014-2015 
> > (that whole Big Tent thing).
> 
> I wouldn't go that far. There are more easy decisions than there were 
> before the reform, but there still exist hard decisions. This is perhaps 
> inevitable.
> 
> > The Project Structure Reform occurred because the TC could not make 
> > decisions on whether projects should join OpenStack using objective 
> > criteria, and due to this, new project applicants were forced to endure 
> > long waits and subjective "graduation" reviews that could change from 
> > one TC election cycle to the next.
> > 
> > The solution to this was to make an objective set of application 
> > criteria and remove the TC from the "Supreme Court of OpenStack" role 
> > that new applicants needed to come before and submit to the court's 
> > judgment.
> > 
> > Many people complained that the Project Structure Reform was the TC 
> > simply abrogating responsibility for being a judgmental body.
> > 
> > It seems that although we've now gotten rid of those objective criteria 
> > for project inclusion and gone back to the TC being a subjective 
> > judgmental body, that the TC is still not actually willing to pass 
> > judgment one way or the other on new project applicants.
> 
> No criteria have been gotten rid of, but even after the Project 
> Structure Reform there existed criteria that were subjective. Here is a 
> thread discussing them during the last TC election:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html
> 
> (I actually think that the perception that the criteria should be 
> entirely objective might be a contributor to the problem: when faced 
> with a subjective decision and no documentation or precedent to guide 
> them, TC members can be reluctant to choose.)

I think turning the decision about which projects fit the mission
into an entirely mechanical one would be a mistake. I would prefer
us to use, and trust, our judgement in cases where the answer needs
some thought.

I don't remember the history quite the way Jay does, either. I
remember us trying to base the decision more about what the team
was doing than how the code looked or whether the implementation
met anyone's idea of "good". That's why we retained the requirement
that the project "aligns with the OpenStack Mission".

> 
> > Is this because it is still remarkably unclear what OpenStack actually 
> > *is* (the whole mission/scope thing)?
> > 
> > Or is this because TC members simply don't want to be the ones to say 
> > "No" to good-meaning people
> 
> I suspect both of those reasons are probably in the mix, along with a 
> few others as well.

There was a good deal of confusion early on about what "workflow" meant
in the context of Adjutant and whether the use of workflows was
overlapping unnecessarily with Mistral. After that was clarified we
talked about the interoperability concerns with an API that may be
different based on deployer choices.

> 
> > that may have an idea that is only 
> > tangentially related to cloud computing?
> 
> It should be noted that in this case Adjutant pretty clearly fills an 
> essential use case for public clouds. The debate was around whether 
> accepting it was likely to lead to the desired standardisation across 
> public OpenStack clouds or effectively act as an official endorsement 
> for API fragmentation.
> 
> It's not clear that any change to the criteria could have made this 
> particular decision any easier.

Only adding a specific rule about the API interoperability would
have addressed my concern directly. I'm not sure applying such a
rule will always make sense (Thierry and Colleen very nearly convinced
me that it would be OK for the Adjutant API on different clouds to
be different, and there may be other cases where the argument is
stronger).

> Things did seem to go more smoothly after we nominated a couple of 
> people to work directly with the project to polish their application, 
> and in retrospect we probably should have treated it with more urgency 
> rather than e.g. waiting for a face-to-face discussion at the Forum 
> before attempting to make progress. Those are the lessons behind the 
> process improvements that we discussed last week that Doug summarised above.

Right. I think both of those discussions dragged on because we
didn't have anyone assigned to drive them and because it took us a
while to clearly communicate the concerns from the TC and the answers
from the Adjutant team. I don't have any issue with any of the
questions that were raised during the review, just with the length
of time it took us.  Identifying coaches to help project teams
through the process, and setting deadlines (similar to review
deadlines for patches) should help us with that.

Doug