<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 7:00 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"><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></blockquote><div><br></div><div>Yup, I was a subscriber of the -tc ML so I noted this draft from ttx's email in December. TBH, I haven't forged any clear opinion yet until you asked about it, so I'll try to give an answer that'll probably evolve over the course of my thinkings.</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">
What parts, if any, of the OIP approval criteria do you think should<br>
apply to OpenStack teams?<br>
<br></blockquote><div><br></div><div> I think the set of criterias necessarly has to be a bit divergent for one reason : the OIP approval has to be driven by the Board (which includes other criterias which can not necessarly be purely technical) while our criterias are managed by the OpenStack *Technical* Committee, meaning that those criterias are necessarly measured by technical key points.</div><div><br></div><div>For example, discussing about strategic focus is totally understandable from a Board point of view but is debatable from a technical point of view.</div><div>The other difference is about user adoption. As we follow a technical guidance, we don't challenge it. We rather just care of the development ecosystem but we even don't take it as a requirement, since we accept a maintenance mode.<br></div><div>Probably worth thinking, but maybe we could investigate the idea to have user-defined tags (thanks to the UC) that would help giving a better view of the user adoptation of each project.</div><div><br></div><div>That being said, most of the criterias I'm seeing on the OIP etherpad look similar to the ones we have for the OpenStack TC :</div><div> - the project has to follow the 4 Opens.</div><div> - it has to communicate well with other Foundation projects</div><div> - it somehow shares same technical best practices</div><div><br></div><div>The last item is interesting, because the OIP draft at the moment shows more technical requirements than the Foundation ones. For example, VMT is - at the moment I'm writing those lines - quoted as a common best practice, which is something we don't ask for our projects. That's actually a good food for thoughts : security is crucial and shouldn't be just a tag [3]. OpenStack is mature and it's our responsibility to care about CVEs.<br></div><div><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">
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></blockquote><div><br></div><div>We have minimum requirements that are expressed with [2] but there are also tags that are expressed by [4]<br></div></div><div class="gmail_quote">One tag I feel is missing is about scalability: we had tenets in the past [5] but I don't see them transcribed into tags. That was one of my three items I mentioned in my candidacy email, but I'd love to see us be better on challenging projects on their scalability model.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
How would you apply those rule changes to existing teams?<br></blockquote><div><br></div><div>I'm more in a favor of an iterative approach with tags first, so that we are able to capture the current problems, and then tackle the problems thru common goals that are well accepted and discussed by all the project teams.</div><div><br></div><div>-Sylvain<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>
[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></blockquote><div><br></div><div> [3] <a href="https://governance.openstack.org/tc/reference/tags/index.html#vulnerability-management-tags">https://governance.openstack.org/tc/reference/tags/index.html#vulnerability-management-tags</a></div><div> [4] <a href="https://governance.openstack.org/tc/reference/tags/index.html">https://governance.openstack.org/tc/reference/tags/index.html</a></div><div> [5] <a href="https://wiki.openstack.org/wiki/BasicDesignTenets">https://wiki.openstack.org/wiki/BasicDesignTenets</a><br></div></div></div></div></div>