Open Stack

Excerpts from Chris Dent's message of 2018-04-23 12:09:42 +0100:
> On Fri, 20 Apr 2018, Doug Hellmann wrote:
> 
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> 
> Thanks for getting the ball rolling on some discussion, Doug.
> 
> > Without letting the conversation devolve too much into a discussion
> > of Adjutant's case, please talk a little about how you would evaluate
> > a project's application in general.  What sorts of things do you
> > consider when deciding whether a project "aligns with the OpenStack
> > Mission," for example?
> 
> This is an important question because project applications are one
> of the few ways in which the TC exercises any direct influence over
> the shape and direction of OpenStack. Much of the rest of the time
> the TC's influence is either indirect or limited. That's something I
> think we should change, in part because I feel the role of the TC
> should be at least as, if not more, focused on the day-to-day
> experiences and capabilities of existing contributors as it is on
> new ones.

Please see my other question about the role of the TC, and being active
or reactive. [1]

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129658.html

> I prefer that we keep a large human factor involved in the
> application process. I do not want us to be purely objective because
> such a process can never take into account the wider and ever
> changing world. The members of the TC can be human info sponges that
> do that accounting. The current process was created in part to
> overcome the far too heavy and nitpicking (and human) previous
> process but it has resulted in what amounts to a dilution in
> direction.
> 
> For me, each application tends to result in a lot of questions such
> as the list I produced on patchset 34 of the Adjutant review[1]. I
> worry that we are predisposed to accept applicants out of a general
> sense of being "nice" and a belief that growth is a sign of health.
> I'm unsure how these behaviors help to drive OpenStack in its
> mission, but while the rules [2] say something as broad as
> 
>       It should help further the OpenStack mission, by providing a
>       cloud infrastructure service, or directly building on an
>       existing OpenStack infrastructure service.
> 
> I feel we're painted into something of a corner where acceptance
> must be the default unless there are egregious interoperability or
> "four opens" violations.
> 
> I'd like to see us work harder to refine the long term goals we are
> trying to satisfy with the projects that make up OpenStack. This
> will require us to continue the never-ending discussion about
> whether OpenStack is a "Software Defined Infrastructure Framework"
> or a "Cloud Solution" (plenty of people talk the latter, but plenty
> of other people are spending energy on the former). And then

Do you consider those two approaches to be mutually exclusive?

In the past our community has had trouble defining "infrastructure"
in a way that satisfies everyone. Some people stop at "allocating
what you need to run a VM" while others consider it closer to
"everything you need to run an application".

How do you define "infrastructure"?

> actually follow through: using the outcome of those discussions to
> impact not just projects that we accept but also where existing
> project focus their attention. We need to be as capable of saying
> an informed "no" as we are of saying "yes".
> 
> In the modern OpenSource world there are so many different
> ecosystems that are cloud friendly: We don't need to provide a home
> for everyone. There are plenty of places for people to go, including
> the many different (and growing) facets of the OpenStack community.
> I would prefer that we be assertive in how we evaluate for alignment
> with the OpenStack mission. Doing that requires fairly constant
> re-evaluation of the mission and a willingness to accept that it
> does (and must) change.
> 
> [1] https://review.openstack.org/#/c/553643/
> [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html
>