Open Stack

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 <morgan.fainberg at gmail.com
> <mailto:morgan.fainberg at gmail.com>> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>