On 7/31/16, 11:29 AM, "Doug Hellmann" <d...@doughellmann.com> wrote:
>Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +0000: >> 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_d >>iv >> 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. > >To be clear, I'm suggesting that projects with team:single-vendor be >given enough time to lose that tag. That does not require them to grow >diverse enough to get team:diverse-affiliation. > >Doug Doug, That makes sense and doesn't send the wrong message. I wasn't trying to suggest that either; was just pointing out Kevin's numbers are more in line with diverse-affiliation than single vendor. My personal thoughts are single vendor projects are ok in OpenStack if they are undertaking community-building activities to increase their diversity of contributors. Regards -steve > >> >> 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 __________________________________________________________________________ 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
