Open Stack

On Wed, May 8, 2019 at 11:27 AM Adam Spiers <aspiers at suse.com> wrote:

> Morgan Fainberg <morgan.fainberg at gmail.com> wrote:
> >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.
>
> IMHO it wouldn't highlight a lack of trust if it explicitly said that
> there is no current problem in the community.
>
> But it's not just about trust.  There's also the issue of simple
> honest lack of awareness, even by diligent newbie cores with the very
> finest of intentions.
>
> Honestly, if I hadn't stumbled across this conversation at the PTG,
> and later became core on a project, it might have never crossed my
> mind that it might be better in some scenarios to avoid giving W+1 on
> a review where +2 was only given by colleagues at my company.  Indeed,
> the fact that we currently (and hopefully indefinitely) enjoy the
> ability to trust the best interests of others cores would probably
> make me *more* susceptible to accidentally introducing
> company-oriented bias without realising it.
>
> In contrast, if there was an on-boarding document for new cores which
> raised awareness of this, I would read that when becoming a core, and
> then vet myself for employer-oriented bias before every +2 and W+1 I
> subsequently gave.
>
> >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.
>
> Agreed.  Any suggestions on how to prevent it being tribal?  The only
> way I can think of is documenting it, but maybe I'm missing a trick.
>

Unfortunately, in this case it's "tribal" or "documented". No "one weird
trick" here as far as I know ;).
--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190508/70c76df8/attachment.html>