Open Stack

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>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151124/0dbb2bc3/attachment.html>