[openstack-dev] [tc] Organizational diversity tag

Tom Barron tpb at dyncloud.net
Mon Jun 4 22:16:08 UTC 2018


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





More information about the OpenStack-dev mailing list