<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 25, 2019 at 3:13 PM Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>> writes:<br>
<br>
> One of the key responsibilities of the Technical Committee is still<br>
> evaluating projects and teams that want to become official OpenStack<br>
> projects. The Foundation Open Infrastructure Project approval process<br>
> has recently produced a different set of criteria for the Board to use<br>
> for approving projects [1] than the TC uses for approving teams [2].<br>
><br>
> What parts, if any, of the OIP approval criteria do you think should<br>
> apply to OpenStack teams?<br>
><br>
> What other changes, if any, would you propose to the official team<br>
> approval process or criteria? Are we asking the right questions and<br>
> setting the minimum requirements high enough? Are there any criteria<br>
> that are too hard to meet?<br>
><br>
> How would you apply those rule changes to existing teams?<br>
><br>
> [1] <a href="http://lists.openstack.org/pipermail/foundation/2019-February/002708.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/foundation/2019-February/002708.html</a><br>
> [2] <a href="https://governance.openstack.org/tc/reference/new-projects-requirements.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/new-projects-requirements.html</a><br>
> -- <br>
> Doug<br>
<br>
One of the criteria that caught my eye as especially interesting was<br>
that a project must complete at least one release before being<br>
accepted. We've debated that rule in the past, and always come down on<br>
the side encouraging new projects by accepting them early. I wonder if<br>
it's time to reconsider that, and perhaps to start thinking hard about<br>
projects that don't release after they are approved.<br>
<br>
Thoughts?<br>
<br></blockquote><div><br></div><div>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".</div><div>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.</div><div>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.</div><div><br></div><div>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 ?</div><div><br></div><div>Hope that clarifies your concern,</div><div>-Sylvain</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Doug<br>
<br>
</blockquote></div></div>