<div dir="ltr">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.<div><br></div><div>But it should be recommended that project apply for the diversity-tag should at least expressed that they have adopted this rule.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 2, 2018 at 3:19 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/06/18 12:18, Doug Hellmann wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Crazy idea: what if we dropped the idea of measuring the diversity and<span class=""><br>
allowed teams to decide when they applied the tag to themselves like we<br>
do for other tags. (No wait! Come back!)<br>
<br>
Some teams enforce a requirement that the 2 core +2s come from reviewers<br>
with different affiliations. We would say that any project that enforces<br>
that rule would get the diversity tag. Then it's actually attached to<br>
something concrete, and teams could decide for themselves when to drop<br>
it (because they would start having difficulty merging stuff otherwise).<br>
<br>
I'm not entirely sold on this, but it's an idea I had that I wanted to<br>
throw out there :)<br>
<br>
cheers,<br>
Zane.<br>
<br>
</span></blockquote><span class="">
<br>
The point of having the tags is to help consumers of the projects<br>
understand their health in some capacity. In this case we were<br>
trying to use measures of actual activity within the project to<br>
help spot projects that are really only maintained by one company,<br>
with the assumption that such projects are less healthy than others<br>
being maintained by contributors with more diverse backing.<br>
</span></blockquote>
<br>
(Clarification for readers: there are actually 3 levels; getting the diverse-affiliations tag has a higher bar than dropping the single-vendor tag.)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does basing the tag definition on whether approvals need to come<br>
from people with diverse affiliation provide enough project health<br>
information that it would let us use it to replace the current tag?<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How many teams enforce the rule you describe?<br>
</blockquote>
<br></span>
I don't know.<br>
<br>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is that rule a sign of a healthy team dynamic, that we would want<br>
to spread to the whole community?<br>
</blockquote>
<br></span>
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).<br>
<br>
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.<br>
<br>
cheers,<br>
Zane.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Product Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div></div></div>
</div>