Open Stack

On Wed, Feb 20, 2019 at 7:00 PM Doug Hellmann <doug at doughellmann.com> wrote:

>
> 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].
>
>
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.

What parts, if any, of the OIP approval criteria do you think should
> apply to OpenStack teams?
>
>
 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.

For example, discussing about strategic focus is totally understandable
from a Board point of view but is debatable from a technical point of view.
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.
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.

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 :
 - the project has to follow the 4 Opens.
 - it has to communicate well with other Foundation projects
 - it somehow shares same technical best practices

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.


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?
>

We have minimum requirements that are expressed with [2] but there are also
tags that are expressed by [4]
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.


How would you apply those rule changes to existing teams?
>

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.

-Sylvain

>
> [1]
> http://lists.openstack.org/pipermail/foundation/2019-February/002708.html
> [2]
> https://governance.openstack.org/tc/reference/new-projects-requirements.html
> --
> Doug
>
>
 [3]
https://governance.openstack.org/tc/reference/tags/index.html#vulnerability-management-tags
 [4] https://governance.openstack.org/tc/reference/tags/index.html
 [5] https://wiki.openstack.org/wiki/BasicDesignTenets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190220/2dba9eb6/attachment.html>