[openstack-dev] [tc] persistently single-vendor projects

Steven Dake (stdake) stdake at cisco.com
Tue Aug 2 13:50:05 UTC 2016



On 8/1/16, 8:38 AM, "Doug Hellmann" <doug at doughellmann.com> wrote:

>Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +0000:
>> I am struggling to understand why we would want to remove projects from
>>our big tent at all, as long as they are being actively developed under
>>the principles of "four opens". It seems to me that working to
>>disqualify such projects sends an alarming signal to our ecosystem. The
>>reason we made the big tent to begin with was to set a tone of
>>inclusion. This whole discussion seems like a step backward. What
>>problem are we trying to solve, exactly?
>> 
>> If we want to have tags to signal team diversity, that's fine. We do
>>that now. But setting arbitrary requirements for big tent inclusion
>>based on who participates definitely sounds like a mistake.
>
>Membership in the big tent comes with benefits that have a real
>cost born by the rest of the community. Space at PTG and summit
>forum events is probably the one that's easiest to quantify and to
>point to as something limited that we want to use as productively
>as possible. If 90% of the work of a project is being done by a
>single company or organization (our current definition for
>single-vendor), and that doesn't change after 18 months, then I
>would take that as a signal that the community isn't interested
>enough in the project to bear the associated costs.
>
>I'm interested in hearing other reasons that we should keep these
>sorts of projects, though. I'm not yet ready to propose the change
>to the policy myself.

Doug,

As a community, we need to carefully consider this action.  The costs to
OpenStack are high for single vendor projects but they do add value if
they behave with community in mind.  I don't think removal from Big Tent
is all that big of a deal as long as the projects can still participate in
the openstack namespace and use gerrit/ci and still be part of OpenStack
as you have previously stated.  My biggest concern is some projects are
really trying hard to increase their diversity while others are not trying
so much.  Unfortunately measuring intent objectively is difficult.  I
severely dislike exceptions, but perhaps projects could apply for
exceptions to this policy change if they are actively digging out of
single vendor by their activities.  Forgive me for singling out a single
project, but deployment is where I've spent the last 3 years of my life
and have an intimate understanding of what is happening in these
communities.

For example tripleo is single-vendor, but is doing all the right things to
dig out of single vendor by doing actual community building.  They aren't
just trying, but are trying *very* hard with their activities.  They have
the right intent but how to measure intent objectively?  That would be my
major concern.

There are more single vendor projects then non-single-vendor projects (the
last time I looked which was several months ago) covering many areas, so
tripleo is just one example of many that may be doing the right things to
build more diverse affiliations.

I don't have any insight into the community building going on in various
communities outside of deployment - perhaps some of those teams PTLs could
weigh in on this thread?

All that said the proposal for 18 months is super generous; Nearly any
project can dig out of single vendor in a 18 month window if they
prioritize it.  It would be better for these projects in the long run to
prioritize moving to more diversity for a whole slew of reasons.  In my 20
years of training, team affiliation diversity is _more_ important than
starting from an empty repository and is a best practice.

To fix the problem, perhaps another tag is needed - something between
single-vendor and diverse-affilliation (spitball -
single-vendor-with-diverse-affiliation.  Single-vendor would have an 18
month window associated with it, while the new tag would guarantee big
tent as long as the objective 90%  percentages were maintained.  The only
problem there is that could put OpenStack back on an
incubation/integration track which from my experience with founding Heat
was a serious hurdle for OpenStack in general and Ceilometer and Heat
specifically.

Regards,
-steve
>
>Doug
>
>> 
>> --
>> Adrian
>> 
>> > On Aug 1, 2016, at 5:11 AM, Sean Dague <sean at dague.net> wrote:
>> > 
>> >> On 07/31/2016 02:29 PM, Doug Hellmann 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.
>> > 
>> > The idea of 3 cycles to loose the single-vendor tag sounds very
>> > reasonable to me. This also is very much along the spirit of the tag
>>in
>> > that it should be one of the top priorities of the team to work on
>>this.
>> > I'd be in favor.
>> > 
>> >    -Sean
>> > 
>> > -- 
>> > Sean Dague
>> > http://dague.net
>> > 
>> > 
>>_________________________________________________________________________
>>_
>> > 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




More information about the OpenStack-dev mailing list