On Tue, Nov 24, 2015 at 6:44 AM, Lance Bragstad <[email protected]> wrote:
> I think one of the benefits of the current model was touched on earlier by > dstanek. If someone is working on something for their organization, they > typically bounce ideas of others they work with closely. This tends to be > people within the same organization. The groups developing the feature > might miss different perspectives on solving that particular problem. > Bringing in a fresh set of eyes from someone outside that organization can > be a huge benefit for the overall product. > > I don't think that is the sole reason to keep the existing policy, but I > do think it's a positive side-effect. > > I would assert that this is a side effect of good development practices and really has not a lot to do with the policy at this point. The policy doesn't really enforce/drive this. The cores are ultimately the gate keepers and should be encouraging the continued reviewing by parties not affiliated with their organization. I don't believe changing this policy will generally have a negative impact on the cross-team reviewing. Cores are always can choose to defer (we do this in many cases) when reviewing as well to encourage the cross org review/view-points. So, yes these are all positive things outlined, I don't think we'd see a significant change on these fronts with a well rounded core group (as we have). Encouraging good development practices is far different than what the not-same-affiliation-for-cores-as-comitter policy accomplishes. I would like to refocus the discussion here back towards the policy itself rather than side-effects that are really a result of a healthy and mature development community. > On Tue, Nov 24, 2015 at 6:31 AM, David Chadwick <[email protected]> > wrote: > >> Spot on. This is exactly the point I was trying to make >> >> David >> >> On 24/11/2015 11:20, Dolph Mathews wrote: >> > Scenarios I've been personally involved with where the >> > "distrustful" model either did help or would have helped: >> > >> > - Employee is reprimanded by management for not positively reviewing & >> > approving a coworkers patch. >> > >> > - A team of employees is pressured to land a feature with as fast as >> > possible. Minimal community involvement means a faster path to "merged," >> > right? >> > >> > - A large group of reviewers from the author's organization repeatedly >> > throwing *many* careless +1s at a single patch. (These happened to not >> > be cores, but it's a related organizational behavior taken to an >> extreme.) >> > >> > I can actually think of a few more specific examples, but they are >> > already described by one of the above. >> > >> > It's not cores that I do not trust, its the organizations they operate >> > within which I have learned not to trust. >> > >> > On Monday, November 23, 2015, Morgan Fainberg < >> [email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi everyone, >> > >> > This email is being written in the context of Keystone more than any >> > other project but I strongly believe that other projects could >> > benefit from a similar evaluation of the policy. >> > >> > Most projects have a policy that prevents the following scenario (it >> > is a social policy not enforced by code): >> > >> > * Employee from Company A writes code >> > * Other Employee from Company A reviews code >> > * Third Employee from Company A reviews and approves code. >> > >> > This policy has a lot of history as to why it was implemented. I am >> > not going to dive into the depths of this history as that is the >> > past and we should be looking forward. This type of policy is an >> > actively distrustful policy. With exception of a few potentially bad >> > actors (again, not going to point anyone out here), most of the >> > folks in the community who have been given core status on a project >> > are trusted to make good decisions about code and code quality. I >> > would hope that any/all of the Cores would also standup to their >> > management chain if they were asked to "just push code through" if >> > they didn't sincerely think it was a positive addition to the code >> base. >> > >> > Now within Keystone, we have a fair amount of diversity of core >> > reviewers, but we each have our specialities and in some cases >> > (notably KeystoneAuth and even KeystoneClient) getting the required >> > diversity of reviews has significantly slowed/stagnated a number of >> > reviews. >> > >> > What I would like us to do is to move to a trustful policy. I can >> > confidently say that company affiliation means very little to me >> > when I was PTL and nominating someone for core. We should explore >> > making a change to a trustful model, and allow for cores (regardless >> > of company affiliation) review/approve code. I say this since we >> > have clear steps to correct any abuses of this policy change. >> > >> > With all that said, here is the proposal I would like to set forth: >> > >> > 1. Code reviews still need 2x Core Reviewers (no change) >> > 2. Code can be developed by a member of the same company as both >> > core reviewers (and approvers). >> > 3. If the trust that is being given via this new policy is violated, >> > the code can [if needed], be reverted (we are using git here) and >> > the actors in question can lose core status (PTL discretion) and the >> > policy can be changed back to the "distrustful" model described >> above. >> > >> > I hope that everyone weighs what it means within the community to >> > start moving to a trusting-of-our-peers model. I think this would be >> > a net win and I'm willing to bet that it will remove noticeable >> > roadblocks [and even make it easier to have an organization work >> > towards stability fixes when they have the resources dedicated to >> it]. >> > >> > Thanks for your time reading this. >> > >> > Regards, >> > --Morgan >> > PTL Emeritus, Keystone >> > >> > >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
