This sounds good to me. What about making it iterative but with a delayed start. Something like:
There is a grace period of 1 year for projects that newly join the big tent. After which, the following criteria will be evaluated to keep a project in the big tent, evaluated at the end of each OpenStack release cycle to keep the project for the next cycle. The project should not have active cores from one company in the amount greater then 45% of the active core membership. If that number is higher, the project is given notice they are under diverse and have 6 months of remaining in the big tent to show they are attempting to increase diversity by shifting the ratio to a more diverse active core membership. The active core membership percentage by the over represented company, called X%, will be shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). If the criteria is met, the project can remain in the big tent and a new cycle will begin. (another notification and 6 months if still out of compliance) This should allow projects that are, or become under diverse a path towards working on project membership diversity. It gives projects that are very far out of wack a while to fix it. It basically gives projects over represented: * (80%, 100%] - gets 18 months to fix it * (60%, 80%] - gets 12 months * (45%, 60%] - gets 6 months Thoughts? The numbers should be fairly easy to change to make for different amounts of grace period. Thanks, Kevin ________________________________________ From: Doug Hellmann [d...@doughellmann.com] Sent: Sunday, July 31, 2016 7:16 AM To: openstack-dev Subject: [openstack-dev] [tc] persistently single-vendor projects Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off" Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200: > Doug Hellmann wrote: > > There is only one way for a repository's contents to be considered > > part of the big tent: It needs to be listed in the projects.yaml > > file in the openstack/governance repository, associated with a > > deliverable from a team that has been accepted as a big tent member. > > > > The Fuel team has stated that they are not ready to include the > > work in these new repositories under governance, and indeed the > > repositories are not listed in the set of deliverables for the Fuel > > team [1]. > > > > Therefore, the situation is clear, to me: They are not part of the > > big tent. > > Reading this thread after a week off, I'd like to +1 Doug's > interpretation since it was referenced to describe the status quo. > > As others have said, we wouldn't even have that discussion if the new > repositories didn't use "fuel" as part of the naming. We probably > wouldn't have that discussion either if the Fuel team affiliation was > more diverse and the new repositories were an experiment of a specific > subgroup of that team. > > NB: I *do* have some concerns about single-vendor OpenStack projects > that don't grow more diverse affiliations over time, but that's a > completely separate topic. I'm starting to think that perhaps we should add some sort of expectation of a time-frame for projects that join the big tent as single-vendor to attract other contributors. We removed the requirement that new projects need to have some minimal level of diversity when they join because projects asserted that they would have a better chance of attracting other contributors after becoming official. It might focus the team's efforts on that priority if we said that after a year or 18 months without any increased diversity, the project would be removed from the big tent. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
