Open Stack

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.

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.

- Graham

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180423/0df9c875/attachment.sig>