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_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.
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 > > 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
