[openstack-dev] [tc] Organizational diversity tag

Zhipeng Huang zhipengh512 at gmail.com
Sat Jun 2 00:43:56 UTC 2018


I agree with Zane's proposal here, it is a good rule to have 2 core
reviewer from different companies to provide +2 for a patch. However it
should not be very strict given that project in early stage usually have to
rely on devs from one or two companies.

But it should be recommended that project apply for the diversity-tag
should at least expressed that they have adopted this rule.

On Sat, Jun 2, 2018 at 3:19 AM, Zane Bitter <zbitter at redhat.com> wrote:

> On 01/06/18 12:18, Doug Hellmann wrote:
>
>> Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400:
>>
>>> Crazy idea: what if we dropped the idea of measuring the diversity and
>>> allowed teams to decide when they applied the tag to themselves like we
>>> do for other tags. (No wait! Come back!)
>>>
>>> Some teams enforce a requirement that the 2 core +2s come from reviewers
>>> with different affiliations. We would say that any project that enforces
>>> that rule would get the diversity tag. Then it's actually attached to
>>> something concrete, and teams could decide for themselves when to drop
>>> it (because they would start having difficulty merging stuff otherwise).
>>>
>>> I'm not entirely sold on this, but it's an idea I had that I wanted to
>>> throw out there :)
>>>
>>> cheers,
>>> Zane.
>>>
>>>
>> The point of having the tags is to help consumers of the projects
>> understand their health in some capacity. In this case we were
>> trying to use measures of actual activity within the project to
>> help spot projects that are really only maintained by one company,
>> with the assumption that such projects are less healthy than others
>> being maintained by contributors with more diverse backing.
>>
>
> (Clarification for readers: there are actually 3 levels; getting the
> diverse-affiliations tag has a higher bar than dropping the single-vendor
> tag.)
>
> Does basing the tag definition on whether approvals need to come
>> from people with diverse affiliation provide enough project health
>> information that it would let us use it to replace the current tag?
>>
>
> Yes. Project teams will soon drop this rule if it's the only way to get
> patches in. A single-vendor project by definition cannot adopt this rule
> and continue to... exist as a project, really.
>
> It would tell potential users that if one organisation drops out it there
> is at least somebody left to review patches, and also guarantee that the
> project's direction is not down to the whim of one organisation.
>
> How many teams enforce the rule you describe?
>>
>
> I don't know.
>
> I do know that in Heat we never enforced it - at first because it was a
> single-vendor project, and then later because it was so diverse (and not
> subject to any particular cross-company animosity) that nobody particularly
> saw the need to change, and now that many of those vendors have pulled out
> of OpenStack because it would be an obstacle to getting patches approved
> again.
>
> I was kind of under the impression that all of the projects used this rule
> prior to Heat and Ceilometer being incubated. That may be incorrect. At
> least Nova and the projects that have a lot of vendor drivers (and are thus
> susceptible to suspicions of bias) - i.e. Cinder & Neutron mainly - may
> still follow this rule? I haven't yet found a mention of it in any of the
> contributor guides though, so possibly it was dropped OpenStack-wide and I
> never noticed.
>
> Is that rule a sign of a healthy team dynamic, that we would want
>> to spread to the whole community?
>>
>
> Yeah, this part I am pretty unsure about too. For some projects it
> probably is. For others it may just be an unnecessary obstacle, although I
> don't think it'd actually be *un*healthy for any project, assuming a big
> enough and diverse enough team (which should be a goal for the whole
> community).
>
> For most projects with small core teams it would obviously be a
> showstopper, but the idea would be for them to continue to opt out.
>
> cheers,
> Zane.
>
>
> __________________________________________________________________________
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng at huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh at uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180602/d4193975/attachment.html>


More information about the OpenStack-dev mailing list