<div dir="ltr">IMO, the goal is that we try to encourage the good, not to get in the way to those who can't reach that goal.<div><br></div><div>A tag is a good way to encourage, but it also not a fair way for those projects who barely got enough core member to review (Think about those projects got less than four active cores). Wondering if anyone got ideas on how we can reach that goal (tag can be a way, just IMO need to provide a fair condition to all).</div><div><br></div><div>How about we set policy and document to encourage people to join core reviewer (this can join forces with the Enterprise guideline we plan in Forum) if they wish to provide diversity to project. </div><div><br></div><div>On the second idea, I think TC (or people who powered by TC) should provide (or guidance project to provide) a health check report for projects. TCs have been looking for <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Liaisons with projects (</span>[1]). This definitely is a good report as a feedback from projects to TC. (also a good way to understand what each project been doing and is that project need any help). So to provide a g<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">uideline for projects to understand how they can do better. </span>Guideline means both -1 and  +1 (for who running projects for long enough to be a core/PTL, should at least understand that -1 only means since this project is under TC's guidance, we just try to help.). Therefore a -1 is important.</div><div><br></div><div>As an alternative, we can also try to target problem when it occurred, but personally wonder who as a single core reviewer in team dear to speak out in this case.</div><div><br></div><div>I think this is a hard issue to do, but we have to pick one action from all actions and try to run and see. And it's better than keep things the way they are and ignore things.</div><div> <br></div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Liaisons">https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Liaisons</a></div><br><div class="gmail_quote"><div dir="ltr">Michael Johnson <<a href="mailto:johnsomor@gmail.com">johnsomor@gmail.com</a>> 於 2018年6月7日 週四 上午2:48寫道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Octavia also has an informal rule about two cores from the same<br>
company merging patches. I support this because it makes sure we have<br>
a diverse perspective on the patches. Specifically it has worked well<br>
for us as all of the cores have different cloud designs, so it catches<br>
anything that would limit/conflict with the different OpenStack<br>
topologies.<br>
<br>
That said, we don't hard enforce this or police it, it is just an<br>
informal policy to make sure we get input from the wider team.<br>
Currently we only have one company with two cores.<br>
<br>
That said, my issue with the current diversity calculations is they<br>
tend to be skewed by the PTL role. People have a tendency to defer to<br>
the PTL to review/comment/merge patches, so if the PTL shares a<br>
company with another core the diversity numbers get skewed heavily<br>
towards that company.<br>
<br>
Michael<br>
<br>
On Wed, Jun 6, 2018 at 5:06 AM,  <<a href="mailto:amrith.kumar@gmail.com" target="_blank">amrith.kumar@gmail.com</a>> wrote:<br>
>> -----Original Message-----<br>
>> From: Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>><br>
>> Sent: Monday, June 4, 2018 5:52 PM<br>
>> To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [tc] Organizational diversity tag<br>
>><br>
>> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400:<br>
>> > On 02/06/18 13:23, Doug Hellmann wrote:<br>
>> > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400:<br>
>> > >> On 01/06/18 12:18, Doug Hellmann wrote:<br>
>> > ><br>
>> > > [snip]<br>
>> > Apparently enough people see it the way you described that this is<br>
>> > probably not something we want to actively spread to other projects at<br>
>> > the moment.<br>
>><br>
>> I am still curious to know which teams have the policy. If it is more<br>
>> widespread than I realized, maybe it's reasonable to extend it and use it as<br>
>> the basis for a health check after all.<br>
>><br>
><br>
> A while back, Trove had this policy. When Rackspace, HP, and Tesora had core reviewers, (at various times, eBay, IBM and Red Hat also had cores), the agreement was that multiple cores from any one company would not merge a change unless it was an emergency. It was not formally written down (to my knowledge).<br>
><br>
> It worked well, and ensured that the operators didn't get surprised by some unexpected thing that took down their service.<br>
><br>
> -amrith<br>
><br>
><br>
> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="background-image:none"><div style="font-size:small"><div><table border="0" cellpadding="0" cellspacing="0" style="color:rgb(0,0,0);font-size:medium;font-family:verdana"><tbody><tr><td colspan="3" align="left"><span style="font-size:13px;font-family:verdana">May The Force of Open<font color="#ff0000">Stack</font> Be With You,</span> <br><b><i><font face="georgia, serif" size="4">Rico Lin<br></font></i></b>irc: ricolin</td></tr><tr><td colspan="3" align="left" style="height:10px;border-bottom:1px dashed rgb(221,221,221)"></td></tr><tr><td colspan="3"></td></tr></tbody></table><br></div></div></div><font size="2" face="tahoma, sans-serif" color="#999999"></font></div></div></div></div></div></div></div></div></div></div></div></div>