Open Stack

On 7/31/16, 11:29 AM, "Doug Hellmann" <doug at 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.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
>> 
>
>__________________________________________________________________________
>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