On 04/06/18 17:52 -0400, Doug Hellmann wrote:
Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400:
On 02/06/18 13:23, Doug Hellmann wrote:
> Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400:
>> On 01/06/18 12:18, Doug Hellmann wrote:
>
> [snip]
>
>>> Is that rule a sign of a healthy team dynamic, that we would want
>>> to spread to the whole community?
>>
>> Yeah, this part I am pretty unsure about too. For some projects it
>> probably is. For others it may just be an unnecessary obstacle, although
>> I don't think it'd actually be *un*healthy for any project, assuming a
>> big enough and diverse enough team (which should be a goal for the whole
>> community).
>
> It feels like we would be saying that we don't trust 2 core reviewers
> from the same company to put the project's goals or priorities over
> their employer's.  And that doesn't feel like an assumption I would
> want us to encourage through a tag meant to show the health of the
> project.

Another way to look at it would be that the perception of a conflict of
interest can be just as damaging to a community as somebody actually
acting on a conflict of interest, and thus having clearly-defined rules
to manage conflicts of interest helps protect everybody (and especially
the people who could be perceived to have a conflict of interest but
aren't, in fact, acting on it).

That's a reasonable perspective. Thanks for expanding on your original
statement.

Apparently enough people see it the way you described that this is
probably not something we want to actively spread to other projects at
the moment.

I am still curious to know which teams have the policy. If it is more
widespread than I realized, maybe it's reasonable to extend it and use
it as the basis for a health check after all.

Just some data. Manila has the policy (except for very trivial or urgent commits, where one +2 +W can be sufficient).

When the project originated NetApp cores and a Mirantis core who was a contractor for NetApp predominated. I doubt that there was any perception of biased decisions -- the PTL at the time, Ben Swartzlander, is the kind of guy who is quite good at doing what he thinks is best for the project and not listening to any folks within his own company who might suggest otherwise, not that I have any evidence of anything like that either :). But at some point someone suggested that our +2 +W rule, already in place, be augmented with a requirement that the two +2s come from different affiliations and the rule was adopted.

So far that seems to work OK though affiliations have shifted and NetApp cores are no longer quantitatively dominant in the project. There are three companies with two cores and so far as I can see they don't tend to vote together more than any other two cores, on the one hand, but on the other hand it isn't hard to get another core +2 if a change is ready to be merged.

None of this is intended as an argument that this rule be expanded to other projects, it's just data as I said.

-- Tom



__________________________________________________________________________
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

Reply via email to