<html><body><p>Tom brings up a good point. With a clear direction and support from the foundation/Thierry I'm confident we can make any version of these models work. I know in the situation I described if the policy was clear that it was okay and if I knew we could pull in Thierry to help resolve any disputes then I'm comfortable we could resolve any issues with a trusting model. I do however hope most patches end up being reviewed by multiple folks coming from different perspectives. The distrust model helped force that. So even if we moved to a more trusting model I'm hoping we see lots of reviews from folks coming from different perspectives and not lots of reviews where a single perspective group think prevails.<br><br>Happy Thanksgiving!<br><br>--Brad<br><br><br>Brad Topol, Ph.D.<br>IBM Distinguished Engineer<br>OpenStack<br>(919) 543-0646<br>Internet: btopol@us.ibm.com<br>Assistant: Kendra Witherspoon (919) 254-0680<br><br><img width="16" height="16" src="cid:1__=0ABBF59BDFC6CECF8f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Tom Fifield ---11/25/2015 01:06:25 AM---On 24/11/15 19:20, Dolph Mathews wrote: > Scenarios I've been"><font color="#424282">Tom Fifield ---11/25/2015 01:06:25 AM---On 24/11/15 19:20, Dolph Mathews wrote: > Scenarios I've been personally involved with where the</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Tom Fifield <tom@openstack.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">openstack-dev@lists.openstack.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">11/25/2015 01:06 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>On 24/11/15 19:20, Dolph Mathews wrote:<br>> Scenarios I've been personally involved with where the<br>> "distrustful" model either did help or would have helped:<br>><br>> - Employee is reprimanded by management for not positively reviewing &<br>> approving a coworkers patch.<br>><br>> - A team of employees is pressured to land a feature with as fast as<br>> possible. Minimal community involvement means a faster path to "merged,"<br>> right?<br>><br>> - A large group of reviewers from the author's organization repeatedly<br>> throwing *many* careless +1s at a single patch. (These happened to not<br>> be cores, but it's a related organizational behavior taken to an extreme.)<br>><br>> I can actually think of a few more specific examples, but they are<br>> already described by one of the above.<br>><br>> It's not cores that I do not trust, its the organizations they operate<br>> within which I have learned not to trust.<br><br>I think this is a good summary of people's fears and practical experience.<br><br>Though, It seems that those cases above are derived from not <br>understanding how we work, rather than out of deliberate malice. We can <br>fix this kind of stuff with education :)<br><br>Putting this out there - over at the Foundation, we're here to Protect <br>and Empower you. So, if you've ever been reprimanded by management for <br>choosing not to abuse the community process, perhaps we should arrange <br>an education session with that manager (or their manager) on how <br>OpenStack works.<br><br><br><br>> On Monday, November 23, 2015, Morgan Fainberg <morgan.fainberg@gmail.com<br>> <</tt><tt><a href="mailto:morgan.fainberg@gmail.com">mailto:morgan.fainberg@gmail.com</a></tt><tt>>> wrote:<br>><br>> Hi everyone,<br>><br>> This email is being written in the context of Keystone more than any<br>> other project but I strongly believe that other projects could<br>> benefit from a similar evaluation of the policy.<br>><br>> Most projects have a policy that prevents the following scenario (it<br>> is a social policy not enforced by code):<br>><br>> * Employee from Company A writes code<br>> * Other Employee from Company A reviews code<br>> * Third Employee from Company A reviews and approves code.<br>><br>> This policy has a lot of history as to why it was implemented. I am<br>> not going to dive into the depths of this history as that is the<br>> past and we should be looking forward. This type of policy is an<br>> actively distrustful policy. With exception of a few potentially bad<br>> actors (again, not going to point anyone out here), most of the<br>> folks in the community who have been given core status on a project<br>> are trusted to make good decisions about code and code quality. I<br>> would hope that any/all of the Cores would also standup to their<br>> management chain if they were asked to "just push code through" if<br>> they didn't sincerely think it was a positive addition to the code base.<br>><br>> Now within Keystone, we have a fair amount of diversity of core<br>> reviewers, but we each have our specialities and in some cases<br>> (notably KeystoneAuth and even KeystoneClient) getting the required<br>> diversity of reviews has significantly slowed/stagnated a number of<br>> reviews.<br>><br>> What I would like us to do is to move to a trustful policy. I can<br>> confidently say that company affiliation means very little to me<br>> when I was PTL and nominating someone for core. We should explore<br>> making a change to a trustful model, and allow for cores (regardless<br>> of company affiliation) review/approve code. I say this since we<br>> have clear steps to correct any abuses of this policy change.<br>><br>> With all that said, here is the proposal I would like to set forth:<br>><br>> 1. Code reviews still need 2x Core Reviewers (no change)<br>> 2. Code can be developed by a member of the same company as both<br>> core reviewers (and approvers).<br>> 3. If the trust that is being given via this new policy is violated,<br>> the code can [if needed], be reverted (we are using git here) and<br>> the actors in question can lose core status (PTL discretion) and the<br>> policy can be changed back to the "distrustful" model described above.<br>><br>> I hope that everyone weighs what it means within the community to<br>> start moving to a trusting-of-our-peers model. I think this would be<br>> a net win and I'm willing to bet that it will remove noticeable<br>> roadblocks [and even make it easier to have an organization work<br>> towards stability fixes when they have the resources dedicated to it].<br>><br>> Thanks for your time reading this.<br>><br>> Regards,<br>> --Morgan<br>> PTL Emeritus, Keystone<br>><br>><br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>><br><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br><br></tt><br><br><BR>
</body></html>