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.fainb...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev