From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-nfp@lists.gentoo.org
Subject: Re: [gentoo-nfp] Agenda item: Formalize Gentoo's org structure
Date: Mon, 09 Apr 2018 18:57:27 +0200 [thread overview]
Message-ID: <1523293047.873.68.camel@gentoo.org> (raw)
In-Reply-To: <20180409102452.mrbt7pkplbcblojt@gentoo.org>
W dniu pon, 09.04.2018 o godzinie 05∶24 -0500, użytkownik Matthew Thode
napisał:
> Gentoo has been known to be a two headed entity for a while. While the
> fact is that only one of the heads has legal standing to be called
> Gentoo, the other head has been doing most of the technical work.
> Unfortunately having two heads means that there can be fighting between
> them. In order to finally put the matter to some rest I seek to define
> Gentoo's org structure.
Currently, legally, it only consists of the following:
> 1. foundation members
> 2. trustees
> 3. officers (don't have to be foundation members or trustees)
>
> I wish to extend that to the following.
> 1. foundation members
> 2. trustees
> 3. officers (don't have to be foundation members or trustees)
> 3.1 infra members (or at least the lead)
> 3.2 comrel members (or at least the lead)
> 3.3 council members
>
> Infrastructure has a clearly defined role in Gentoo. Namely that of
> managing foundation infrastructure resources. Bringing those members
> under the foundation's umbrella formalizes this. Infra has previously
> been fairly nebulous as to who directs them (having been directed by
> council, trustees and comrel).
>
> Comrel has the clear analog of being the HR (human relations). HR
> is three to protect the business from human related infighting. Comrel
> was previously under the direction of the council, primarily for
> historical reasons (the foundation was not well staffed or run until
> recently). I thank the council for managing this.
>
> Council is supposed to be the technical leadership within Gentoo, over
> the last decade or so this responsibility has ballooned to encompass
> things out side this scope. This seeks to clearly define the powers of
> the council to that of technical leadership.
>
>
> One of the drawbacks of this is that being an officer means being an
> 'organ' of the business, meaning that some of the current members may
> have conflicts with their current job. To this I ask 'Is what you are
> doing now not vital? If it is doesn't that make you an organ (even if
> not explicitly stated as such)?'
>
> One of the good things about this (other than clearly defining roles and
> boundaries) is that it allows council members to server as Trustees.
> This would require a bylaw change, but has been something often
> complained about.
>
Matthew, I'm not sure where to start.
Maybe I should start by apologizing for the length of this mail.
I really hate to waste your time having to read all of this but in this
case I believe things have gone too far just to leave things half-
answered or risk misinterpretation.
I find this proposal outrageous. It is a clear attack on Gentoo
developers' right to self-govern. While I wouldn't call Gentoo an exact
democracy, your proposal sounds like bureaucrat dictatorship. I will
detail on it later on.
But before that, I would like to ask why do you keep pushing forward
a proposal that has seen so much negative feedback? And why do you try
to push it via gentoo-nfp when you are perfectly aware that the previous
discussions on gentoo-project have brought much negative feedback? Are
you trying to avoid this feedback?
Do you believe that the minor changes you've made meet the expectations
of all the developers who did not like your initial proposal? Do you
believe in it so much that you do not feel it appropriate to ask for
their opinion on the updated proposal?
Do you believe that the developers have suddenly changed their mind
and are ready to abandon self-governing themselves in favor of
dictatorship of bureaucrats? Do you believe that the recent attacks of
William L. Thompson Jr., Daniel Campbell or Daniel Robbins have achieved
that goal? Or maybe the gentoo-dev posting restrictions? Do you know
that for sure?
Or are you just trying to use sheer force of repetition? Are you going
to push the same proposal over and over again until people agree with it
just to be done with hearing about it? Or just until they get
frustrated enough and stop replying? Then you could claim you had no
negative feedback on 15th reiteration of the same proposal.
But let's get to the details.
Your proposal -- once again -- makes Trustees the highest-level
governing body of Gentoo and reduces Council to technical matters. This
is against GLEP 39 which clearly states that Council is responsible for
all global decisions and as far as I'm aware is the most recent policy
defining the role of Council. Unless you have a strong reason to
believe that this policy has been illegally forced upon Gentoo, you are
not 'formalizing' anything but attempting to change well-established
metastructure and outright lying to the community that the current state
is undefined.
I believe that Trustees can't be the highest governing body of Gentoo
for a number of reasons. I will enumerate those I can think of below:
1. Trustee elections are not even half as democractic as Council
elections.
With no 'reopen nominations', with the ability to accept Trustees
without a vote or for existing Trustees to appoint new Trustees for
missing slots, and finally with low interest in developers becoming
Trustees, this is effectively 'Trustee seat giveaway' and not
an election. This is already bad enough for governing the Foundation
and I am fully against extending this to governing the whole of Gentoo.
And if you believe that reducing the power of Council will suddenly
convince developers to increase their interest in becoming Trustees, you
are wrong, for reasons outlined in further points.
2. Bad Trustee work... increases their chances of re-election.
Given that each new Trustee takes legal responsibility about the state
of Foundation, he/she is directly endangered by repercussions of any
problems within the Foundation, including problems caused by previous
Trustees. As far as I'm aware, we hadn't established any clear way of
new Trustees protecting themselves against this, and most of the new
candidates aren't really capable of suing previous board 'just in case'
as Kristian suggested.
As a result, if Trustees leave Foundation in a bad state (which has been
the case so far), then a number of candidates is going to refuse
the nomination because they do not want to take responsibility for
mistakes of their predecessors. And this goes on recursively. At this
point, even if Trustees finally managed to finish IRS as they claim
they'll do, I personally would still have serious doubt whether I could
really trust things are fully solved.
3. Trustees have direct control over their electorate.
Who votes for Trustees? Foundation members. And who appoints
and removes Foundation members? Trustees, of course. So we're talking
about giving away governing the whole distribution to people who
directly decide who can vote for them, and who can't, and do that
in rather arbitrary way.
Before somebody claims that Council is in the same situation -- not
exactly. The Council doesn't directly interfere with recruitment
or retirement -- it only takes care of appeals. Not to mention that
the rules for becoming a developer are far more precise than rules for
becoming a Foundation member.
4. Not everyone can be a legal Foundation representative.
This has been the argument a lot of people mentioned. Some of our
developers simply can't legally be an Officer, not to mention Trustee
because of their employment or other legal positions. Your proposal
unjustly prevents them from having any governing position.
5. You are conflating governing and bureaucracy.
What we have right now is two disjoint bodies: Council which is elected
as representatives of developers, and Trustees who are responsible for
dealing with the bureaucracy. With your proposal, developers are now
partially governed by bureaucrats for no real reason except... we need
bureaucrats, and bureaucrats want to rule us.
What you're doing here is blocking competent people who were doing a
good job dealing with non-technical matters on the Council just because
they do not have the necessary skills or experience to do the Trustee
work. And on the other hand, giving power to people who may not be
trusted developer representatives just because they claim they're going
to take care of the bureaucracy.
6. Trustees have serious problems dealing with their own work.
Let's be honest. Trustees haven't been exactly the perfect caretakers
of legal and financial matters. Even skipping the tax problems, let's
talk about copyright problems. Rich Freeman has started the work on
solving them long time ago. Then Trustees were responsible for it
and did not manage to do anything except for copying the Rich's text
with minor changes (also made by him) to Wiki.
The whole copyright effort started again when I established the 'joint
venture'. Which was pretty much a nice way of saying 'we will do most
of it for you because otherwise it will never happen'. But sure, that
was a complex problem.
Just take a look at their meeting logs and see how many items keep being
moved from month to month with no action taken:
https://wiki.gentoo.org/wiki/Foundation:Meetings
At some point, you start thinking that Trustees are putting more effort
in trying to replace Council than in actually doing the things they were
elected to do. Do you really think they will be doing a better job with
more responsibilities at hand?
7. Who will oversee the Trustees?
Right now, the Council handles all the global decisions and appeals
in Gentoo. However, if Council goes rogue and starts working against
the goals of Gentoo, Trustees can intervene. If Trustees become the
highest authority for decisions and appeals, who is going to intervene?
That's all I can think of now. But I think that's 7 reasons too many
for Trustees to claim any direct leadership position. Trustees have
a clearly defined role in serving and protecting Gentoo. Extending that
to exercising daily power in leading Gentoo is not going to be good
for the community, and certainly it is not going to be fair to other
developers.
--
Best regards,
Michał Górny
next prev parent reply other threads:[~2018-04-09 16:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 10:24 [gentoo-nfp] Agenda item: Formalize Gentoo's org structure Matthew Thode
2018-04-09 11:08 ` Luca Barbato
2018-04-09 12:58 ` Alec Warner
2018-04-09 14:49 ` Matthew Thode
2018-04-09 13:01 ` Alec Warner
2018-04-09 13:23 ` Rich Freeman
2018-04-09 15:09 ` Matthew Thode
2018-04-09 16:57 ` Michał Górny [this message]
2018-04-09 17:50 ` Matthew Thode
2018-04-09 19:11 ` Ulrich Mueller
2018-04-09 19:22 ` Matthew Thode
2018-04-10 17:28 ` Michał Górny
2018-04-10 17:47 ` Matthew Thode
2018-04-10 18:04 ` Daniel Robbins
2018-04-10 18:08 ` Matthew Thode
2018-04-10 19:23 ` Michał Górny
2018-04-10 19:39 ` Matthew Thode
2018-04-10 19:41 ` Michał Górny
2018-04-10 19:47 ` Matthew Thode
2018-04-10 19:54 ` Michał Górny
2018-04-10 19:56 ` Matthew Thode
2018-04-10 20:50 ` Michał Górny
2018-04-10 20:58 ` Matthew Thode
2018-04-10 21:05 ` Michał Górny
2018-04-10 21:08 ` Matthew Thode
2018-04-10 19:58 ` Daniel Robbins
2018-04-10 19:48 ` Daniel Robbins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1523293047.873.68.camel@gentoo.org \
--to=mgorny@gentoo.org \
--cc=gentoo-nfp@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox