Open Stack

On Mon, Feb 25, 2019 at 3:19 PM Sylvain Bauza <sbauza at redhat.com> wrote:

>
>
> On Mon, Feb 25, 2019 at 3:13 PM Doug Hellmann <doug at doughellmann.com>
> wrote:
>
>> Doug Hellmann <doug at doughellmann.com> writes:
>>
>> > One of the key responsibilities of the Technical Committee is still
>> > evaluating projects and teams that want to become official OpenStack
>> > projects. The Foundation Open Infrastructure Project approval process
>> > has recently produced a different set of criteria for the Board to use
>> > for approving projects [1] than the TC uses for approving teams [2].
>> >
>> > What parts, if any, of the OIP approval criteria do you think should
>> > apply to OpenStack teams?
>> >
>> > What other changes, if any, would you propose to the official team
>> > approval process or criteria? Are we asking the right questions and
>> > setting the minimum requirements high enough? Are there any criteria
>> > that are too hard to meet?
>> >
>> > How would you apply those rule changes to existing teams?
>> >
>> > [1]
>> http://lists.openstack.org/pipermail/foundation/2019-February/002708.html
>> > [2]
>> https://governance.openstack.org/tc/reference/new-projects-requirements.html
>> > --
>> > Doug
>>
>> One of the criteria that caught my eye as especially interesting was
>> that a project must complete at least one release before being
>> accepted. We've debated that rule in the past, and always come down on
>> the side encouraging new projects by accepting them early. I wonder if
>> it's time to reconsider that, and perhaps to start thinking hard about
>> projects that don't release after they are approved.
>>
>> Thoughts?
>>
>>
> My personal opinion on that is that releasing a 1.0 version is just
> procedural. Or, said differently, political. It's just a signal saying "we
> think we are ready for production".
> The problem with that is that it's subjective. No real key metrics to
> attribute the meaning of "production-ready" (I'm even not talking of
> production-grade), just a feeling that the contributors team ideally, or
> just the "PTL" (given the project isn't official yet), considers it ready.
> As a consequence, there can be a big gap in between the contributors's
> expectations and the reality. That's what I called it "the reality wall".
> When you hit it, it's a pain.
>
> I'm more in favor of objective metrics to define the health of a project
> in order to be production ready : does this project allow upgrades ? is
> this project distributed enough to grow atomically ? can we easily provide
> bugfixes thanks to a stable policy ?
>
> Hope that clarifies your concern,
> -Sylvain
>
>
Looking again at your question, I think I haven't answered the main
question. Should we accept a project even if it's not yet ready (and
doesn't match the points I said above) ?
Well, I surely understand the big interest in getting approved as an
official project. Keep in mind I was a Climate/Blazar contributor in 2013
;-) By that time, the project wasn't official (it was pre-Tent so the
approval process was a bit different) so we faced the same visibility issue
than most of the small projects face I guess. That said, even knowing how
much is a pain to attract new contributors, getting approved doesn't get
you those resources magically.
In order to get some contributors, you first need to find some companies
that are willing to dedicare some of their own resources into your project.
That's not a matter of being ready or not, it's more a matter of seeing a
business case behind the project.

For that precise reason, I don't really think it helps our projects to be
approved very early as official projects. We should rather promote some
incubation approach (and we did that with Stackforge and it was great for a
small project like we were in 2013) and maybe have the TC members to
shepherd those candidates in order to give them some light and visibility
so that corporate sponsors could know of their existence, but the main step
would still remain.

HTH,
-Sylvain

-- 
>> Doug
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190225/d27f0f77/attachment.html>