Open Stack

Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
> 7On 20/04/18 22:26, Doug Hellmann wrote:
> <snip/>
> > 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?
> > 
> > Doug
> > 
> 
> For me, the most important thing for a project that wants to join is
> that they act like "one of us" - what I think ttx refered to as "culture
> fit".
> 
> This is fairly wide ranging, but includes things like:
> 
> * Do they use the PTIs[0]
> * Do they use gerrit, or if they use something else, do they follow
>   the same review styles and mechanisms?
> * Are they on IRC?
> * Do they use the mailing list for long running discussion?
>   ** If a project doesn't have long running discussions and as a result
>      does not have ML activity, I would see that as OK - my problem
>      would be with a team that ran their own list.
> * Do they use standard devstack / -infra jobs for testing?
> * Do they use the standard common libraries (where appropriate)?
> 
> If a project fails this test (and would have been accepted as something
> that drives the mission), I see no issue with the TC trying to bring
> them into the fold by helping them work like one of us, and accepting
> them when they have shown that they are willing to change how they
> do things.
> 
> For the "product" fit, it is a lot more subjective. We used to have a
> system (pre Big Tent) where the TC picked "winners" in a space and
> blessed one project as the way to do $thing. Then, in big tent we
> started to not pick winners, and allow anyone who was one of us, and
> had a "cloud" application.
> 
> Recently, we have moved back to seeing if a project overlaps with
> another. The real test for this (from my viewpoint) is if the
> perceived overlap is an area that the team that is currently in
> OpenStack is interested in pursuing - if not we should default to
> adding the project.

We've always considered overlap to some degree, but it has come up
more explicitly in a few recent discussions because of the nature
of the projects.  Please see the other thread on this topic [1].

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

> Personally, if the project adds something that we currently lack,
> and have lacked for a long time (not to get too close to the current
> discussion), or tries to reduce the amount of extra tooling that
> deployers currently write in house, we should welcome them.
> 
> The acid test for me is "How would I use this?" or "Have I written
> tooling or worked somewhere that wrote tooling to do this?"
> 
> If the answer is yes, it is a good indication that they fit with the
> mission.

This feels like the ideal open source approach, in which contributors
are "scratching their own itch." How can we encourage more deployers
and users of OpenStack to consider contributing their customization
and integration projects? Should we?

Doug

> 
> - Graham
> 
> 0 -
> https://governance.openstack.org/tc/reference/project-testing-interface.html