On 04/06/18 17:52, 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.
At least Nova still does, judging by this comment from Matt Riedemann in
January:
"For the record, it's not cool for two cores from the same company to be
the sole +2s on a change contributed by the same company. Pretty
standard operating procedure."
(on https://review.openstack.org/#/c/523958/18)
When this thread started I looked for somewhere that was documented more
permanently, but I didn't find it.
The appealing part of the idea to me was that we could stop pretending
that the results of our mindless script are objective - despite the fact
that both the subset of information to rely on and the limits in the
script were chosen by someone, in an essentially arbitrary way - and let
the decision rest on the expertise of those who are closest to the
project (and therefore have the most information), while aligning their
incentives with the needs of users so that they're not being asked to
keep their own score. I'm always on the lookout for opportunities to do
that, so I felt like I had to at least float it.
The alignment goes both ways though, and if we'd be creating an
incentive to extend the coverage of a policy that is already
controversial then this is not the way forward.
cheers,
Zane.
__________________________________________________________________________
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
