On 23/04/18 16:04, Doug Hellmann wrote: > 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?
I think a lot of our major users are good citizens and are doing some or all of this work in the open - we just have a discoverability issue. A lot of the benefit of joining the foundation as a project, is the increased visibility gained from it, so that others who are deploying OpenStack in a similar layout can find a project and use it. I think at the very least we should find a way to promote them (this is where constellations could really help, as we could add non member projects to constellations where they are appropriate. > Doug > >> >> - Graham >> >> 0 - >> https://governance.openstack.org/tc/reference/project-testing-interface.html > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
