On 25/02/2019 14:09, Doug Hellmann wrote:
Doug Hellmann <doug@doughellmann.com> writes:
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].
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
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?
How would you apply those rule changes to existing teams?
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html -- Doug One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
My response to your initial email was that we should focus more on going forward. I stand by that. This is an interesting addition to the OIP acceptance criteria, especially considering that we also considered it originally and for multiple reasons we reconsidered this option. I don't think it would be a bad idea to implement this, maybe it would genuinely be a good idea - it should at least be discussed. It would reflect the maturation of the preexisting projects and their integration with each other.