Kevin, Just assessing your numbers, the team:diverse-affiliation tag covers what is required to maintain that tag. It covers more then core reviewers - also covers commits and reviews.
See: https://github.com/openstack/governance/blob/master/reference/tags/team_div erse-affiliation.rst I can tell you from founding 3 projects with the team:diverse-affiliation tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to meet. I don't think its wise to have such strict requirements on single vendor projects as those objectively defined in team:diverse-affiliation. But Doug's suggestion of timelines could make sense if the timelines gave plenty of time to meet whatever requirements make sense and the requirements led to some increase in diverse affiliation. The 45% core requirement sort of goes against the tag name "single-vendor". I know of many single vendor projects that would like to have a diverse affiliation, strive for it, and actively promote the integration of new community members into their respective sub-communities. We don't want to send these folks the wrong message they aren't welcome. Regards -steve On 7/31/16, 8:59 AM, "Fox, Kevin M" <kevin....@pnnl.gov> wrote: >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 __________________________________________________________________________ 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
