<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:19 PM Sylvain Bauza <<a href="mailto:sbauza@redhat.com">sbauza@redhat.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"><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" target="_blank">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></div></div></blockquote><div><br></div><div>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) ?</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>HTH,</div><div>-Sylvain<br></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"><div dir="ltr"><div class="gmail_quote"><div></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>
</blockquote></div></div>