<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 8, 2019, 09:09 Ed Leafe <<a href="mailto:ed@leafe.com">ed@leafe.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On May 8, 2019, at 10:45 AM, Adam Spiers <<a href="mailto:aspiers@suse.com" target="_blank" rel="noreferrer">aspiers@suse.com</a>> wrote:<br>
> <br>
>> 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. <br>
>> Documenting our culture is a good thing, but embodying that documentation with this sort of nuance can be challenging. <br>
> <br>
> 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" ?<br>
<br>
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.<br>
<br>
<br>
-- Ed Leafe<br> </blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"></div></div>