Open Stack

Thanks Doug :) see responses inline below.

On 20/02/2019 17:58, Doug Hellmann 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].

To be open and honest, I have mostly been a bystander during this change.

> What parts, if any, of the OIP approval criteria do you think should
> apply to OpenStack teams?
I want to start by saying I agree with Sylvain, he noted that this set of
criteria has primarily been driven by the board, but it has also been driven
by community members, Foundation staff, the TC, and the UC who have all
been long-term members of the open source community and OpenStack.
I would also like to note that your question does not specify whether
or not you are talking about pre-existing OpenStack teams or new teams. 
Since we are
talking about the future TC, I am going to assume "new" projects for my 
answer. But
if I am wrong, Doug, could you please clarify and I will happily review 
my answer if
there are changes to be made.

The requirements for new projects [2] has continuously been iterated on over
the years, and it ultimately reflects the beginning of the community and 
what
we believed was an important criteria set. The development process and the
writing of the OIP approval criteria is seasoned with experts from the 
key use cases.
We have had experience writing this type of thing before, and therefore 
it is a more
formal set of Confirmation Guidelines.

That being said, to answer your question truthfully (IMHO): The 
guidelines for introducing
a new OpenStack team is not as relevant as they once were. A quick search
(and it is not covering all bases, just the majority) returned a list 
[3] indicating that
in the last 18 months we have accepted more removals of projects, more 
integration
of sub-projects than new projects to the OpenStack ecosystem. I am making my
comparisons to 2015 - 2017 where we saw a surge of new projects
throwing their hat into the ring. It was very important during that 
point in time to
govern those projects ensuring they met OpenStack community guidelines. 
At this point in the
OpenStack product lifecycle, I see this as a better opportunity for the 
new phase
(OIP) to learn from us, rather than the other way around.

This is not to say that we can not continue to iterate on what it means 
to be
a successful OpenStack project and apply great changes. But I believe we 
should
be looking forwards.The new OSF Guidelines for OIP clearly has similar 
criteria to
the requirements for new OpenStack projects. As already noted, those are:

     - 4 opens
     - Communication

TL;DR - What we have is good. We can learn from the experience's OIP 
will encounter, but
we must stop looking behind us to fix what isn't broken.
> 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?
I actually do not have anything to add to this. I think our official 
team approval process
and criteria for what it is worth - is good. We have just begun the work 
to fully
integrate OIP into our ecosystem, let's focus on the future.
> [1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html
> [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html
[3] 
https://review.openstack.org/#/q/project:+openstack/governance+file:+projects.yaml+branch:+master+(new-project)