Open Stack

On Wed, May 8, 2019, 09:09 Ed Leafe <ed at leafe.com> wrote:

> On May 8, 2019, at 10:45 AM, Adam Spiers <aspiers at suse.com> wrote:
> >
> >> I have a feeling that a big part of why it's gone undocumented for so
> long is that putting it in writing risks explicitly sending the message
> that we don't trust our contributors to act in the best interests of the
> project even if those are not aligned with the interests of their
> employer/sponsor. I think many of us attempt to avoid having all activity
> on a given patch come from people with the same funding affiliation so as
> to avoid giving the impression that any one organization is able to ram
> changes through with no oversight, but more because of the outward
> appearance than because we don't trust ourselves or our colleagues.
> >> Documenting our culture is a good thing, but embodying that
> documentation with this sort of nuance can be challenging.
> >
> > That's a good point.  Maybe that risk could be countered by explicitly
> stating something like "this is not currently an issue within the
> community, and it has rarely, if ever, been one in the past; therefore this
> policy is a preemptive safeguard rather than a reactive one" ?
>
> I think that’s a good approach. This way if such a situation comes up and
> people wonder why others are questioning it, it will be all above-board.
> The downside of *not* documenting this concern is that in the future if it
> is ever needed to be mentioned, the people involved might feel that the
> community is suddenly ganging up against their company, instead of simply
> following documented policy.
>
>
> -- Ed Leafe
>


In general I would rather see trust be pushed forward. The cores are
explicitly trusted individuals within a team. I would encourage setting
this policy aside and revisit if it ever becomes an issue. I think this
policy, preemptive or not, highlights a lack of trust. It is another reason
why Keystone team abolished the rule.  AI.kuch prefer trusting the cores
with landing code with or without external/additional input as they feel is
appropriate.

There are remedies if something lands inappropriately (revert, removal of
core status, etc). As stated earlier in the quoted email, this has never or
almost never been an issue.

With that said, I don't have a strongly vested interest outside of seeing
our community succeeding and being as open/inclusive as possible (since
most contributions I am working on are not subject to this policy). As long
as the policy isn't strictly tribal knowledge, we are headed in the right
direction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190508/53603393/attachment.html>