[nova][all][ptg] Summary: Same-Company Approvals

Adam Spiers aspiers at suse.com
Wed May 8 18:27:19 UTC 2019


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.



More information about the openstack-discuss mailing list