<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 8, 2019 at 11:27 AM Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>> wrote:<br>
>In general I would rather see trust be pushed forward. The cores are<br>
>explicitly trusted individuals within a team. I would encourage setting<br>
>this policy aside and revisit if it ever becomes an issue. I think this<br>
>policy, preemptive or not, highlights a lack of trust.<br>
<br>
IMHO it wouldn't highlight a lack of trust if it explicitly said that<br>
there is no current problem in the community.<br>
<br>
But it's not just about trust.  There's also the issue of simple<br>
honest lack of awareness, even by diligent newbie cores with the very<br>
finest of intentions.<br>
<br>
Honestly, if I hadn't stumbled across this conversation at the PTG,<br>
and later became core on a project, it might have never crossed my<br>
mind that it might be better in some scenarios to avoid giving W+1 on<br>
a review where +2 was only given by colleagues at my company.  Indeed,<br>
the fact that we currently (and hopefully indefinitely) enjoy the<br>
ability to trust the best interests of others cores would probably<br>
make me *more* susceptible to accidentally introducing<br>
company-oriented bias without realising it.<br>
<br>
In contrast, if there was an on-boarding document for new cores which<br>
raised awareness of this, I would read that when becoming a core, and<br>
then vet myself for employer-oriented bias before every +2 and W+1 I<br>
subsequently gave.<br>
<br>
>It is another reason<br>
>why Keystone team abolished the rule.  AI.kuch prefer trusting the cores<br>
>with landing code with or without external/additional input as they feel is<br>
>appropriate.<br>
><br>
>There are remedies if something lands inappropriately (revert, removal of<br>
>core status, etc). As stated earlier in the quoted email, this has never or<br>
>almost never been an issue.<br>
><br>
>With that said, I don't have a strongly vested interest outside of seeing<br>
>our community succeeding and being as open/inclusive as possible (since<br>
>most contributions I am working on are not subject to this policy). As long<br>
>as the policy isn't strictly tribal knowledge, we are headed in the right<br>
>direction.<br>
<br>
Agreed.  Any suggestions on how to prevent it being tribal?  The only<br>
way I can think of is documenting it, but maybe I'm missing a trick.<br></blockquote><div><br></div><div>Unfortunately, in this case it's "tribal" or "documented". No "one weird trick" here as far as I know ;).</div><div>--Morgan </div></div></div>