Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Jeremy Stanley]

On 2015-11-23 21:20:56 + (+), David Chadwick wrote:
> Since the ultimate arbiter is the PTL, then it would be wrong to allow
> members of the same organisation as the PTL to perform all three code
> functions without the input of anyone from any other organisation. This
> places too much power in the hands of one organisation to the detriment
> of the overall community.

The ultimate arbiter is the body of contributors who elect the PTL.
If I begin making questionable or downright abusive decisions, a
majority of contributors can hold an interim election and oust me at
any time they see fit.
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Jeremy Stanley]

On 2015-11-25 14:02:47 +0800 (+0800), Tom Fifield wrote:
[...]
> 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.

Further, it's been my observation so far that those heavily involved
in upstream OpenStack development have no shortage of alternative
job offers (and I would definitely count core reviewers of larger
projects such as those under discussion to fall into this category).
If they're finding themselves in an oppressive employment situation,
that employer will quickly lose their influence within the community
through key employee attrition. It's a problem which has a tendency
to self-correct over time, so hopefully our member companies are
figuring this dynamic out for themselves. ;)
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Jeremy Stanley]

On 2015-11-24 11:43:26 +0100 (+0100), Thierry Carrez wrote:
> Right. The code is either in and supported by everyone, or out.
[...]

And as mentioned in Morgan's original post, it can be both at
different points in time. Contributions should be approved or not on
their own merits and not those of the people submitting them or the
companies at which they work. If it turns out later that meritless
code was merged, it can still be undone by others in the community
(though as Brad pointed out in his reply, to the possible detriment
in reputation of those who approved it in the first place).

I find it's preferable to review code without thinking about who
wrote it, though admittedly that's sometimes easier said than done.
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Brad Topol]

Tom brings up a good point.   With a clear direction and support from the
foundation/Thierry I'm confident we can make any version of these models
work.  I know in the situation I described if the policy was clear that it
was okay and if I knew we could pull in Thierry to help resolve any
disputes then I'm comfortable we could resolve any issues with a trusting
model.   I do however hope most patches end up being reviewed by multiple
folks coming from different perspectives.  The distrust model helped force
that.  So even if we moved to a more trusting model I'm hoping we see lots
of reviews from folks coming from different perspectives and not lots of
reviews where a single perspective group think prevails.

Happy Thanksgiving!

--Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Tom Fifield <t...@openstack.org>
To: openstack-dev@lists.openstack.org
Date:   11/25/2015 01:06 AM
Subject:    Re: [openstack-dev] [keystone][all] Move from active
    distrusting model to trusting model



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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Tom Fifield]

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 > 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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Morgan Fainberg]

On Tue, Nov 24, 2015 at 6:44 AM, Lance Bragstad  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 
> 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 <
>> 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 

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Brad Topol]

Lance makes some very good points below.  I agree fully with them.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Lance Bragstad <lbrags...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   11/24/2015 09:56 AM
Subject:        Re: [openstack-dev] [keystone][all] Move from active
    distrusting model to trusting model



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.

On Tue, Nov 24, 2015 at 6:31 AM, David Chadwick <d.w.chadw...@kent.ac.uk>
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 <
  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 po

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Henry Nash]

Good, wide ranging discussion.

From my point of view, this isn’t about trusting cores, rather (as was pointed 
out by others) ensuring people with different customer perspectives be part of 
the approval. Of course, you could argue they could have -1’d it anyway, but I 
think ensuring cross-company approval helps us overall, and so I’m comfortable 
and support with the existing approach.

Henry
> On 24 Nov 2015, at 09:06, Henry Nash  wrote:
> 
> Good, wide ranging discussion.
> 
> From my point of view, this isn’t about trusting cores, rather (as was 
> pointed out by others) ensuring people with different customer perspectives 
> be part of the approval. Of course, you could argue they could have -1’d it 
> anyway, but I think ensuring cross-company approval helps us overall, and so 
> I’m comfortable and support with the existing approach.
> 
> Henry
>> On 24 Nov 2015, at 05:55, Clint Byrum > > wrote:
>> 
>> Excerpts from Adam Young's message of 2015-11-23 20:21:47 -0800:
>>> On 11/23/2015 11:42 AM, Morgan Fainberg 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.
>>> 
>>> So, having been one of the initial architects of said policy, I'd like 
>>> to reiterate what I felt at the time.  The policy is in place as much to 
>>> protect the individual contributors as the project.  If I was put in a 
>>> position where I had to review and approve a coworkers code changes, it 
>>> is is easier for me to push back on a belligerent manager to say "this 
>>> violates project policy."
>>> 
>>> But, even this is a more paranoid rationale than I feel now.  Each of us 
>>> has a perspective based on our customer base.   People make decisions 
>>> based on what they feel to be right, but right for a public cloud 
>>> provider and right for an Enterprise Software vendor will be different.  
>>> Getting a change reviewed by someone outside your organization is for 
>>> perspective.  Treat it as a brake against group think.
>>> 
>>> I know and trust all of the current Keystone core very well.  I 

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Thierry Carrez]

Clint Byrum wrote:
> Excerpts from Brad Topol's message of 2015-11-23 13:38:34 -0800:
>> So to avoid the perception of a single company owning a piece of code,  at
>> IBM our policy for major projects like Cinder, Nova and currently many
>> parts of Keystone (except pycadf) is to make sure we do not do the
>> following for major OpenStack projects:
>>* Employee from Company IBM writes code
>>* Other Employee from Company IBM reviews code
>>* Third Employee from Company IBM  reviews and approves code.
>>
>> Again for certain small projects we relax this rule.  And certainly we
>> could discuss relaxing this rule for larger portions of Keystone if needed.
>> But as a general policy we strive to stick to the distrust model as much as
>> we can as the "perception of impropriety" that exists with the  trusting
>> model can result in tangible headaches.
> 
> Thanks Brad. I think this is an interesting example where it's not
> the single organization that is not being trusted by the community,
> but the community that is not being trusted by the single organization.
> Their behavior may be warranted, but IMO a community member refusing to
> respect a contribution because it is from a single organization that
> is not theirs is an example of a community member misbehaving, which
> I feel should be dealt with quietly but swiftly. We should strive to
> understand anyone who feels this way, and do what we can to _address_
> their concerns, instead of avoiding them.

Right. The code is either in and supported by everyone, or out. If some
contributors object to the code being in, that should be resolved when
the code is being proposed (or initially merged), rather than by
assuming some areas of the code are now a specific organization's fault
(and therefore segmenting your code maintenance duties).

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Julien Danjou]

On Mon, Nov 23 2015, Morgan Fainberg wrote:

> 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.

This is yet another case of permission-vs-forgiveness. Trustful is the
model we applied from the beginning the Telemetry team with great
success. And we never had any abuse of this.

In the end it comes down to picking correctly your core reviewers. Not
by setting the bar immensely high, but by building trust step by step,
and bonding, in such a way that the peer trust becomes more important
than the company pressure.

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Lance Bragstad]

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.

On Tue, Nov 24, 2015 at 6:31 AM, David Chadwick 
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  > > 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
> >
> >
> >
> >
> 

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Duncan Thomas]

On 24 November 2015 at 06:21, Adam Young  wrote:

>
> So, having been one of the initial architects of said policy, I'd like to
> reiterate what I felt at the time.  The policy is in place as much to
> protect the individual contributors as the project.  If I was put in a
> position where I had to review and approve a coworkers code changes, it is
> is easier for me to push back on a belligerent manager to say "this
> violates project policy."
>
> But, even this is a more paranoid rationale than I feel now.  Each of us
> has a perspective based on our customer base.   People make decisions based
> on what they feel to be right, but right for a public cloud provider and
> right for an Enterprise Software vendor will be different.  Getting a
> change reviewed by someone outside your organization is for perspective.
> Treat it as a brake against group think.
>
>

I don't think cinder has ever formalised on this policy, and I don't
necessarily think it should, but having it there as strong guidance is
definitely useful in order to push back against internal management
pressure when needed. It isn't a matter of trust, or even group think
(though that can definitely be a problem) but one of giving developers (iin
this case cores) the tools they need to push back against pressure inside
their own companies.

In a similar vein, many well meaning and hard working engineers hit massive
problems trying to get resources for CI until we started removing drivers
from tree. Companies, particularly big ones, are slow moving, difficult to
steer behemoths at times, and giving cores the tools to protect themselves,
or devs more tools to help them get their job done, is definitely something
we need to keep in mind.

Personally, my biggest indicator of a 'forced' review is time - if
something has been open for two weeks with zero negative feedback, on an
uncontentious topic, then I really don't care too much who approves it. If
something lands in four hours during the European night on a topic that has
been bounced around a lot on IRC/email then I get more worried, regardless
of the organisation(s) of the cores who merged it. No amount of rules will
fix that though, only discussion and trust of cores. Giving them a rule to
stand behind when saying 'no' to their management chain is a great help
though.

-- 
Duncan Thomas
__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[David Chadwick]

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  > 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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Dolph Mathews]

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 
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2015-11-23 09:17:06 -0800:
> Morgan Fainberg wrote:
> > [...]
> > 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.
> 
> +1
> 
> There are so many ways to abuse strict rules that it's better to have a
> loose, trust-by-default policy and a strong history of fixing the
> mistakes and abuses whenever they arise.
> 

I second this response, third the position that we should trust each
other first.

All of the objections that have been raised boil down to that fundamental
issue.

If we are going to distrust people, let's have a reason, not a theory. How
about evidence of instances when _three_ employees from a company colluded
to merge a bad change in any OpenStack project.

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[David Chadwick]

On 23/11/2015 21:59, Clint Byrum wrote:
> Excerpts from David Chadwick's message of 2015-11-23 13:20:56 -0800:
>> Since the ultimate arbiter is the PTL, then it would be wrong to allow
>> members of the same organisation as the PTL to perform all three code
>> functions without the input of anyone from any other organisation. This
>> places too much power in the hands of one organisation to the detriment
>> of the overall community.
>>
> 
> This is just a vote for distrusting the community. If you think there's
> "power" in being able to merge things, and that organizations will abuse
> this power, then you vote for distrust.

No, rather for the abuse of power by organisations, which is rather
different :-) We have multiple examples of these all the time.

> 
> However, I don't think PTLs have power to censure anybody nor do they
> have absolute arbitration powers. They break ties. Whatever discretion
> they have can almost certainly be overridden by the TC according to this:
> 
> "...  if a given debate cannot be clearly resolved, the PTL can decide
> the outcome. Although the TC is generally not involved in team-internal
> decisions, it still has oversight over team decisions, especially when
> they affect other teams or go contrary to general OpenStack goals."
> 
> http://governance.openstack.org/reference/charter.html#project-team-leads
> 
> So I think if a PTL were to act improperly in a way that the project
> team disagreed with, it would be well within the right and charter of
> the TC to intervene as part of oversight.
> 
> __
> 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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[David Chadwick]

Very sensible policy, Brad. Congrats to IBM for it

On 23/11/2015 21:38, Brad Topol wrote:
> Hi Morgan,
> 
> So lots of good points below. However I am pulled in two directions on
> this topic.
> 
> For small projects (e.g. pycadf, heat-translator) there are so few cores
> and the project is small in size that we as project cores permit two
> people from the same company as the code author to both +2 and then +A.
> On these projects we simply could not make progress if we did not have
> this trusting model.
> 
> For the larger projects like Cinder, the trusting model has led to
> trouble in the past. I have seen where if there was a piece of code
> where the following happens:
> 
> * Employee from Company A writes code
> * Other Employee from Company A reviews code
> * Third Employee from Company A reviews and approves code.
> 
> Then what can happen is the community looks at that code as Company
> A's code not the community code. Thus when there are bugs in that
> code they come back to company A and say "You put this code in all
> by yourself, its buggy and you need to maintain it all by yourself".
> If I was working for company B that seems like a pretty natural
> reaction especially if it turns out the code requires lots of
> maintenance. This was a real scenario and I was on the side (Company
> A) getting the spanking from folks from a very irritated company B.
> 
> So to avoid the perception of a single company owning a piece of code,
> at IBM our policy for major projects like Cinder, Nova and currently
> many parts of Keystone (except pycadf) is to make sure we do not do the
> following for major OpenStack projects:
> 
> * Employee from Company IBM writes code
> * Other Employee from Company IBM reviews code
> * Third Employee from Company IBM reviews and approves code.
> 
> Again for certain small projects we relax this rule. And certainly we
> could discuss relaxing this rule for larger portions of Keystone if
> needed. But as a general policy we strive to stick to the distrust model
> as much as we can as the "perception of impropriety" that exists with
> the trusting model can result in tangible headaches.
> 
> Thanks,
> 
> Brad
> 
> 
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: bto...@us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
> 
> Inactive hide details for Morgan Fainberg ---11/23/2015 12:08:09 PM---On
> Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur  ---11/23/2015 12:08:09 PM---On Mon, Nov 23, 2015 at 8:51 AM, Dmitry
> Tantsur <dtant...@redhat.com> wrote: > On 11/23/2015 05:42 P
> 
> From: Morgan Fainberg <morgan.fainb...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 11/23/2015 12:08 PM
> Subject: Re: [openstack-dev] [keystone][all] Move from active
> distrusting model to trusting model
> 
> 
> 
> 
> 
> 
> On Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur <_dtantsur@redhat.com_
> <mailto:dtant...@redhat.com>> wrote:
> 
> On 11/23/2015 05:42 PM, Morgan Fainberg 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.
> 
> Thanks for raising this. I always apply this policy in ironic not
> because I don't think we're trustful with my colleagues. The problem
> I'm t

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Clint Byrum]

Excerpts from David Chadwick's message of 2015-11-23 13:20:56 -0800:
> Since the ultimate arbiter is the PTL, then it would be wrong to allow
> members of the same organisation as the PTL to perform all three code
> functions without the input of anyone from any other organisation. This
> places too much power in the hands of one organisation to the detriment
> of the overall community.
> 

This is just a vote for distrusting the community. If you think there's
"power" in being able to merge things, and that organizations will abuse
this power, then you vote for distrust.

However, I don't think PTLs have power to censure anybody nor do they
have absolute arbitration powers. They break ties. Whatever discretion
they have can almost certainly be overridden by the TC according to this:

"...  if a given debate cannot be clearly resolved, the PTL can decide
the outcome. Although the TC is generally not involved in team-internal
decisions, it still has oversight over team decisions, especially when
they affect other teams or go contrary to general OpenStack goals."

http://governance.openstack.org/reference/charter.html#project-team-leads

So I think if a PTL were to act improperly in a way that the project
team disagreed with, it would be well within the right and charter of
the TC to intervene as part of oversight.

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Clint Byrum]

Excerpts from Brad Topol's message of 2015-11-23 13:38:34 -0800:
> So to avoid the perception of a single company owning a piece of code,  at
> IBM our policy for major projects like Cinder, Nova and currently many
> parts of Keystone (except pycadf) is to make sure we do not do the
> following for major OpenStack projects:
>* Employee from Company IBM writes code
>* Other Employee from Company IBM reviews code
>* Third Employee from Company IBM  reviews and approves code.
> 
> Again for certain small projects we relax this rule.  And certainly we
> could discuss relaxing this rule for larger portions of Keystone if needed.
> But as a general policy we strive to stick to the distrust model as much as
> we can as the "perception of impropriety" that exists with the  trusting
> model can result in tangible headaches.
> 

Thanks Brad. I think this is an interesting example where it's not
the single organization that is not being trusted by the community,
but the community that is not being trusted by the single organization.
Their behavior may be warranted, but IMO a community member refusing to
respect a contribution because it is from a single organization that
is not theirs is an example of a community member misbehaving, which
I feel should be dealt with quietly but swiftly. We should strive to
understand anyone who feels this way, and do what we can to _address_
their concerns, instead of avoiding them.

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Adam Young]

On 11/23/2015 11:42 AM, Morgan Fainberg 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.


So, having been one of the initial architects of said policy, I'd like 
to reiterate what I felt at the time.  The policy is in place as much to 
protect the individual contributors as the project.  If I was put in a 
position where I had to review and approve a coworkers code changes, it 
is is easier for me to push back on a belligerent manager to say "this 
violates project policy."


But, even this is a more paranoid rationale than I feel now.  Each of us 
has a perspective based on our customer base.   People make decisions 
based on what they feel to be right, but right for a public cloud 
provider and right for an Enterprise Software vendor will be different.  
Getting a change reviewed by someone outside your organization is for 
perspective.  Treat it as a brake against group think.


I know and trust all of the current Keystone core very well.  I have no 
expectation that any of them would violate the policy, even given the 
looser interpretation.






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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Clint Byrum]

Excerpts from Adam Young's message of 2015-11-23 20:21:47 -0800:
> On 11/23/2015 11:42 AM, Morgan Fainberg 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.
> 
> So, having been one of the initial architects of said policy, I'd like 
> to reiterate what I felt at the time.  The policy is in place as much to 
> protect the individual contributors as the project.  If I was put in a 
> position where I had to review and approve a coworkers code changes, it 
> is is easier for me to push back on a belligerent manager to say "this 
> violates project policy."
> 
> But, even this is a more paranoid rationale than I feel now.  Each of us 
> has a perspective based on our customer base.   People make decisions 
> based on what they feel to be right, but right for a public cloud 
> provider and right for an Enterprise Software vendor will be different.  
> Getting a change reviewed by someone outside your organization is for 
> perspective.  Treat it as a brake against group think.
> 
> I know and trust all of the current Keystone core very well.  I have no 
> expectation that any of them would violate the policy, even given the 
> looser interpretation.
> 

Adam this has been enlightening. I'm not sure I would do things the same
way, but I do have a greater understanding now of why things are the way
they are, and I fully respect that it has worked out O-K thus far. Thanks.

__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[David Stanek]

On Mon, Nov 23, 2015 at 6:06 PM David Chadwick 
wrote:
[snip]

> >
> > This is just a vote for distrusting the community. If you think there's
> > "power" in being able to merge things, and that organizations will abuse
> > this power, then you vote for distrust.
>
> No, rather for the abuse of power by organisations, which is rather
> different :-) We have multiple examples of these all the time.
>

I don't know if it's fair to say that voting for the current, strict rules
is the same as voting for distrust. I also don't know if it's fair to say
that we have multiple examples of organizations abusing power without
clarifying if you mean in our community.

As I said earlier I can see these rules as being protective. Similar to how
organizations have lots of rules about getting gifts from suppliers,
customers, etc. and a variety of other 'conflict of interest' situations.
Much of that is useful to avoid the appearance of impropriety. Simple rules
can keep you out of some bad situations.

Is that valuable at all within our community? Is that valuable to protect
our community from outside forces?

-- David
__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Morgan Fainberg]

On Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur  wrote:

> On 11/23/2015 05:42 PM, Morgan Fainberg 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.
>>
>
> Thanks for raising this. I always apply this policy in ironic not because
> I don't think we're trustful with my colleagues. The problem I'm trying to
> avoid is members of the same company having the same one-sided view on a
> problem.
>
>
A change of this policy doesn't preclude reaching out for more view points,
and that should always be done. This is part of trusting the cores to know
when this is valuable. :) Thanks for joining the convo here!


>
>> 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.
>>
>
> This is probably a fair use case for not applying this rule.
>
>
>> 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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Thierry Carrez]

Morgan Fainberg wrote:
> [...]
> 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.

+1

There are so many ways to abuse strict rules that it's better to have a
loose, trust-by-default policy and a strong history of fixing the
mistakes and abuses whenever they arise.

-- 
Thierry Carrez (ttx)

__
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-dev] [keystone][all] Move from active distrusting model to trusting model

[Morgan Fainberg]

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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Dmitry Tantsur]

On 11/23/2015 05:42 PM, Morgan Fainberg 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.


Thanks for raising this. I always apply this policy in ironic not 
because I don't think we're trustful with my colleagues. The problem I'm 
trying to avoid is members of the same company having the same one-sided 
view on a problem.




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.


This is probably a fair use case for not applying this rule.



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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[David Stanek]

On Mon, Nov 23, 2015 at 11:52 AM Dmitry Tantsur  wrote:

> On 11/23/2015 05:42 PM, Morgan Fainberg wrote:
> > Hi everyone,
> >
>
[snip,snip]

> >
> > This type of policy is an actively distrustful policy.
>

I don't see it quite like that. I don't think the policy is there because
I'm not trusted to make good decisions, I see it more as protecton from the
appearance that I am doing it.

I trust all of the Keystone cores and would have no issue lifting the
policy. The question is if that opens us up to scrutiny (or anything else)
from outside our development group. I don't know the history behind the
policy, so I can't answer that question.

-- David
__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Matt Fischer]

On Mon, Nov 23, 2015 at 9:42 AM, Morgan Fainberg 
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
>


I happen to disagree with it in the general case. Developers, even cores or
especially cores, can be subject to political and career pressure to get
changes merged. Some employees are judged by managers on the number of
commits/features they land. This puts pressure on them to push things
through. I hope this is the exception, but I think it does happen. Part of
being a core is wielding influence, soft power in other words; it's not
unreasonable to expect a core reviewer to be able to get a +2 from someone
outside their company. That's my opinion on the general case.

In the specific case of a project like puppet-openstack, we are not a large
team of reviewers and so although we generally try our best to avoid having
+2s from the same company or merging each other's work, it does sometimes
happen. We still strive to have at least one +2 from someone outside our
company. So I think some projects are already doing this (we are) but it
requires a strong PTL who is willing to call out abuse and an understanding
amongst the cores about what the social policy is.

So on a project-by-project basis I think rules may already be bent/modified
by the teams. I'm not sure if they're codified anywhere other than just
known as an expectation.
__
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

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[David Chadwick]

Since the ultimate arbiter is the PTL, then it would be wrong to allow
members of the same organisation as the PTL to perform all three code
functions without the input of anyone from any other organisation. This
places too much power in the hands of one organisation to the detriment
of the overall community.

David

On 23/11/2015 17:12, Matt Fischer wrote:
> On Mon, Nov 23, 2015 at 9:42 AM, Morgan Fainberg
> > 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
> 
> 
> 
> I happen to disagree with it in the general case. Developers, even cores
> or especially cores, can be subject to political and career pressure to
> get changes merged. Some employees are judged by managers on the number
> of commits/features they land. This puts pressure on them to push things
> through. I hope this is the exception, but I think it does happen. Part
> of being a core is wielding influence, soft power in other words; it's
> not unreasonable to expect a core reviewer to be able to get a +2 from
> someone outside their company. That's my opinion on the general case.  
> 
> In the specific case of a project like puppet-openstack, we are not a
> large team of reviewers and so although we generally try our best to
> avoid having +2s from the same company or merging each other's work, it
> does sometimes happen. We still strive to have at least one +2 from
> someone outside our company. So I think some projects are already doing
> this (we are) but it requires a strong PTL who is willing to call out
> abuse and an understanding amongst the cores about what the social
> policy is. 
> 
> So on a project-by-project basis I think rules may already be
> bent/modified by the teams. I'm not sure if they're codified anywhere
> other than just known as an expectation.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Brad Topol]

Hi Morgan,

So lots of good points below.  However I am pulled in two directions on
this topic.

For small projects (e.g. pycadf, heat-translator)   there are so few cores
and the project is small in size that we as project cores permit two people
from the same company as the code author to both +2 and then +A.   On these
projects we simply could not make progress if we did not have this trusting
model.

For the larger projects like Cinder, the trusting model has led to trouble
in the past.   I have seen where if there was a piece of code where the
following happens:
   * Employee from Company A writes code
   * Other Employee from Company A reviews code
   * Third Employee from Company A reviews and approves code.

   Then what can happen is the community looks at that code as Company A's
   code not the community code.  Thus when there are bugs in that code they
   come back to company A and say "You put this code in all by yourself,
   its buggy and you need to maintain it all by yourself".If I was
   working for company B that seems like a pretty natural reaction
   especially if it turns out the code requires lots of maintenance.  This
   was a real scenario and I was on the side (Company A) getting the
   spanking from folks from a very irritated company B.

So to avoid the perception of a single company owning a piece of code,  at
IBM our policy for major projects like Cinder, Nova and currently many
parts of Keystone (except pycadf) is to make sure we do not do the
following for major OpenStack projects:
   * Employee from Company IBM writes code
   * Other Employee from Company IBM reviews code
   * Third Employee from Company IBM  reviews and approves code.

Again for certain small projects we relax this rule.  And certainly we
could discuss relaxing this rule for larger portions of Keystone if needed.
But as a general policy we strive to stick to the distrust model as much as
we can as the "perception of impropriety" that exists with the  trusting
model can result in tangible headaches.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Morgan Fainberg <morgan.fainb...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   11/23/2015 12:08 PM
Subject:    Re: [openstack-dev] [keystone][all] Move from active
distrusting model to trusting model





On Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur <dtant...@redhat.com>
wrote:
  On 11/23/2015 05:42 PM, Morgan Fainberg 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.

  Thanks for raising this. I always apply this policy in ironic not because
  I don't think we're trustful with my colleagues. The problem I'm trying
  to avoid is members of the same company having the same one-sided view on
  a problem.


A change of this policy doesn't preclude reaching out for more view points,
and that should always be done. This is part of trusting the cores to know
when this is valuable. :) Thanks for joining the convo here!


   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.

  This is probably a fair use case for not applying this rule.


   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)