Re: [gentoo-project] Re: Trying to become a Gentoo Developer again spanning 8 years...

[Daniel Campbell]

On 10/06/2016 06:06 PM, Rich Freeman wrote:
> NP already gave a good response but I wanted to elaborate on the
> conflict of interest topic.
>
> On Thu, Oct 6, 2016 at 8:32 PM, Daniel Campbell <zlg@g.o> wrote:
>> Additionally, we should think about conflicts of interest. Should we let
>> people act on both the Council and in Comrel?
>
> This has been a topic of several long discussions.  Personally I see
> no conflict of interest, and it is common in the real world for judges
> to serve on panels that decide cases, and also serve on larger panels
> that handle appeals of the same cases.  A conflict of interest is when
> somebody stands to benefit personally from the outcome of a decision,
> apart from the organization they represent.  So, if somebody were
> deciding whether to engage the services of a company they own on the
> side, that would be a conflict of interest, because even if the
> company screws up and harms Gentoo, they still benefit personally.
>
> That is my opinion on the matter.  It seems like a majority of people
> who have commented on this in the past disagree with me, and there are
> a few places in the official docs that suggest that Comrel members
> should not participate in Council appeals of decisions.  To date
> Comrel members have recused themselves from Council appeals.  So,
> while I think most of the community is wrong on this, and Gentoo's
> standards are inconsistent with how most organizations and governments
> are run, ultimately I don't make the rules (we Council members try to
> follow the rules, and certainly I'd expect to be called on it if I
> didn't).  Most in the community seem to prefer having the appeal be
> handled independently from the original decision, feeling that a
> second set of eyes could reach a different decision.  Certainly some
> courts work this way as well, though I don't think any would call this
> a result of a "conflict of interest."
>
>> I recall certain
>> situations call for council members to abstain from certain votes. Is
>> that true of matters involving Comrel as well? QA? There are multiple
>> "pits" of power, and I think we as a project should do what we can to
>> ensure that powers between groups don't become imbalanced as one or a
>> small group consolidate power among themselves and use it as a weapon.
>
> To date Comrel members have been recusing themselves from Council
> appeals.  I personally disagree that this is necessary, but all the
> same the result is that all Council appeals to date have been
> independent decisions.
>
> In any case, anybody who is in both Comrel and Council is only on the
> Council because they were elected as such.  So, they already have the
> trust of most of the community.  I don't personally get why you'd
> trust them with the bigger decisions and not with the smaller ones as
> well, but...
For me, it's about separation of exposure. A Comrel member who has it
out for someone (or alternatively, has been failing to find a solution
to a problem for months) is not going to have a (relatively) unbiased
opinion or clear judgment on a given case. Comrel is sorta like the
defense or prosecution, while the Council is the judge. The prosecution
and judge should not ever be in cahoots with each other, or the
integrity of the process falters.

I would personally find it hard to take a decision at face value if I
learned that one or more members held "office" in other pivotal
positions. Seeing someone recuse from voting is a great start, and a
sign that there is some integrity. Perhaps excusing themselves from
Council decisions altogether (for that case, including sharing
information) may be a better step, at least until we get more people
interested in these positions.

Otherwise, we have a difference in opinion but I think we both value
integrity and impartial actors judging a case from the outside.
>
> The other challenge with having completely separate
> Council/Trustee/Comrel/QA (and I'd throw Infra in as one of those
> other special projects) is that ultimately there are only so many
> people that have that level of trust/maturity/leadership/etc in the
> community.  I think it is healthy to try to minimize overlap just from
> the standpoint of getting more hands involved and not letting one
> person become a bottleneck.  Nevertheless, I'd rather have somebody
> wearing two hats if they're competent, than putting somebody who isn't
> competent in power simply because we've run out of warm bodies willing
> to do the job.  At one point in time we actually had trouble filling
> all the Trustee slots, and several of the past Trustee elections have
> been vacant.  I know that in private there have been discussions and
> the occasional conscious decision for people in these sorts of roles
> to not run for re-election just to try to encourage new blood to stop
> up, or to get out of the way of those who would benefit from
> experience.  When Council members can't make meetings we try to find
> proxies and that is also another avenue to expose people to the role.
>
> Bringing up new leaders is always a challenge because the stuff the
> leadership tends to deal with is often qualitatively different from
> the stuff ordinary devs do.  You can't just look at the quality of
> somebody's commits and decide that they'd make a good member of
> Comrel.  Perhaps we need to find more minor roles that devs hold as a
> stepping stone, and to also help spread the work.
>
I like the idea for minor roles. Start with forum mod work or something
like that, to see how a candidate acts when given a little bit of power.
How they handle that role will reveal how they act under pressure and
when their hand is forced by unruly behavior. Given that the power is
trivially granted or taken away, and the decisions they make can also be
reversed in fast order, I think it would be a wonderful step to motivate
developers to become more involved with the community.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6