Open Stack

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.Fox at 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 [doug at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>