Open Stack

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.)

> 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.

> 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.

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.

cheers,
Zane.