[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-project
Subject:    Re: [gentoo-project] Gentoo Council 2014 / 2015 election
From:       Rich Freeman <rich0 () gentoo ! org>
Date:       2014-07-04 16:12:09
Message-ID: CAGfcS_kmqOdhE1dwuspmVPFZ9ANnah_qzLY=8GK11zX+sRhfiQ () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jul 4, 2014 at 10:39 AM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
> On Fri, 4 Jul 2014, Rich Freeman wrote:
>> 1.  Announced elections, membership changes, etc.  When these things
>> happen, publish it on -project, or at least on the team page.  Make it
>> easy for everybody to see what is going on with the
>> membership/leadership of ComRel.  There is no need for the annual lead
>> election to be secret.
>
>
> If you mean the ballots should be public, I disagree...
> If you mean that the result of an election should be public, I agree.

We're on the same page here.

> I agree with you that changes to policies should be discussed in the mls. We
> did that a few years ago. We definitely need to publish the resulting policy
> so everyone is aware of it.

Again, we're actually on the same page here.  I wasn't suggesting a
free-for-all with conflict resolution.

>
>> 3.  This is a bigger change, but I'd advocate doing with ComRel what
>> was done last year with QA.  Have the team self-governing for the most
>> part, but with the Council having to confirm the lead and basically
>> having the effective ability to take over if necessary.  I'd highly
>> discourage the Council ever doing that, but I'd look at it a bit like
>> being able to Impeach or Recall an elected official - just a way to
>> have accountability and the mandate that goes along with that.
>
>
> I strongly object to this idea, just like I did with QA.
> The goal / purpose of ComRel is not to be "cozy" team that everyone feels
> great with. To have an effective ComRel team, it needs to be made of people
> with certain traits (level headed, fair, independent, trustworthy) that do
> their work with the best interest of Gentoo "at heart". That's why it can't
> be a "open to everyone" team.
> Besides, the council can always revert ComRel decisions and it always had
> the power to deal with a "rotten" ComRel or ComRel lead.

I'm not actually sure we're disagreeing here.  This isn't about the
Council picking the members of QA or ComRel.  This is about having
both teams govern themselves, but submitting their choice of leads to
the Council to be blessed.  I just view it as a way of "legitimizing"
the teams, and making the elected Council members accountable for
their actions.

I was not proposing having open elections for these teams, or open
membership as with most Gentoo teams.

>
> Even though I agree that there's a more visible QA team now, I don't
> necessarily agree that we're better now. I hope and expect the new team will
> get better with time, but they've been dragged into many and noisy
> conflicts, which have even lead to complaints to ComRel.

So, I can't say that I've agreed with how every issue has been
handled, but it is a new team and I believe that creffet has been
working hard to try to get the team to find the right balance between
inactivity and overactivity.  Of course a QA team that actually does
things will trigger more ComRel complaints than one that does nothing
- that's just the nature of the beast.  The last month or two seems to
have been fairly quiet judging from the lists and Council agendas.

> Your setting of a precedent also worries me as a way for any particular new
> council to decide it's time to replace QA, just because the 2013/2014
> council did it.

The Council didn't replace QA, it populated it.  There basically
weren't any active members in QA when we did it.  The GLEP clearly
outlines how this year's Council agreed to do it in the future (not
that future Councils couldn't change this).  The QA lead basically
holds the final say over what QA does, as is the structure of all of
our projects in theory.  In practice they shouldn't be ruling with an
iron hand.  QA chooses its own members, and they elect the lead.  The
lead then has to be confirmed by the Council, and I would generally
expect that to be a rubber stamp most of the time.  However, if there
is an issue that is an opportunity for reform.

But, if for whatever reason things really got out of hand, then
Council absolutely should clean house if that is what they feel is the
best option.  What is the alternative?  We can't have a Gentoo with
half a dozen self-governing fiefdoms all doing whatever they feel is
best regardless of what the overall developer community thinks.

I'm not an advocate of the Council stepping on teams like
QA/ComRel/Infra, but these are special teams that I believe require
some kind of mandate.  If your team isn't going to let any developer
join, even if for good reason, then there needs to be some kind of
accountability to the rest of the community.  Otherwise people start
complaining about cliques/etc.

So, I'm an advocate of the Council being the buck-stops-here team, and
if developers have a problem with our performance, they get the
opportunity to get rid of us.  Then all the grievances get aired, and
we can all look at the results of an election and agree that they are
fair.  Sure, we'll still have our differences, but at least we can say
that the majority of devs are happy with what is going on.

But, accountability of ComRel is something for the next Council to
decide on.  I've been clear on my views - I want QA/ComRel/Infra to be
subordinate to the Council, but self-governing in the day-to-day.  I
don't have strong feelings on whether ComRel/Infra are subordinate to
the Council vs the Trustees - I think that they should be under one or
the other but it could go either way.  I also have stated before that
I think that QA >> ComRel > Infra as far as priority of reform goes as
well - QA was dysfunctional last fall and needed immediate action,
ComRel and especially Infra are less broken and thus we shouldn't be
in as much of a rush to "fix" them.

Rich


[prev in list] [next in list] [prev in thread] [next in thread]