[openstack-dev] [tc] notes from stein ptg meetings of the technical committee

Doug Hellmann doug at doughellmann.com
Mon Sep 17 22:51:19 UTC 2018

Excerpts from Jay Pipes's message of 2018-09-17 17:07:43 -0400:
> On 09/17/2018 04:50 PM, Doug Hellmann wrote:
> > 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".
> Hmm. I very specifically remember the incubation and graduation review 
> of Zaqar and the fact that over a couple cycles of TC elections, the 
> "advice" given by the TC about specific technical implementation details 
> changed, often arbitrarily, depending on who was on the TC and what day 
> of the week it was. In fact, I pretty vividly remember this arbitrary 
> nature of the architectural review being one of the primary reasons we 
> switched to a purely objective set of criteria.

I remember talking about objectivity, but I also remember that we
stopped reviewing aspects of a project like it's architecture or
implementation details to avoid having the case you describe recur.
I remember that because I had a hard time coming around to that
point of view, at first.

You're correct, however, that the resolution we adopted as the first
step toward the big tent change
does talk about making decisions based on team practices and projects
fitting the mission as being objective requirements. And the patch
that implemented the first part of the big tent change
(https://review.openstack.org/#/c/145740/14) also talks about

It's interesting that we took different things away from the same
discussion. :-)

In any case, I think we've learned there is still quite a bit of
subjectivity in the question about whether a project fits the

> Also, for the record, I actually wasn't referring to Adjutant 
> specifically when I referred in my original post to "only tangentially 
> related to cloud computing". I was referring to my recollection of 
> fairly recent history. I remember the seemingly endless debates about 
> whether some applicants "fit" the OpenStack ecosystem or whether the 
> applicant was merely trying to jump on a hype bandwagon for marketing 
> purposes. Again, I wasn't specifically referring to Adjutant here, so I 
> apologize if my words came across that way.

This topic came up in the meeting because of the Adjutant evaluation
taking so long.


More information about the OpenStack-dev mailing list