Open Stack

On 5/8/19 1:50 PM, Morgan Fainberg wrote:
> 
> 
> On Wed, May 8, 2019 at 11:27 AM Adam Spiers <aspiers at suse.com 
> <mailto:aspiers at suse.com>> wrote:
> 
>     Morgan Fainberg <morgan.fainberg at gmail.com
>     <mailto: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 ;).

Two cores, one company. You won't believe what happens next!

/me goes back to daydreaming about working on a project with enough 
contributors for this to be a problem :-)