Doug Hellmann <doug@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
--
Doug