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:+project...)