On 24/11/15 19: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.
I think this is a good summary of people's fears and practical experience.
Though, It seems that those cases above are derived from not
understanding how we work, rather than out of deliberate malice. We can
fix this kind of stuff with education :)
Putting this out there - over at the Foundation, we're here to Protect
and Empower you. So, if you've ever been reprimanded by management for
choosing not to abuse the community process, perhaps we should arrange
an education session with that manager (or their manager) on how
OpenStack works.
On Monday, November 23, 2015, Morgan Fainberg <morgan.fainb...@gmail.com
<mailto: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
__________________________________________________________________________
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
