Re: [gentoo-project] Foundation membership and who can join

[Ian Stakenvicius]

On 14/10/16 08:43 AM, Rich Freeman wrote:
> On Fri, Oct 14, 2016 at 8:08 AM, Ian Stakenvicius <axs@g.o> wrote:
>>
>> The tricky technical part here that I worry about is the Gentoo Dev
>> <-> Gentoo Staff assertion, and the hard
>> staff-must-be-foundation-member and foundation-member-must-be-staff
>> rules listed above.  Loss of foundation membership seems that it must
>> remove staff status by definition, but since dev's are staff simply
>> because they're dev's, are they still a dev when they lose their staff
>> status?
>>
>
> Yes
>
>> Now, there may well be good reason to force the Dev<->Foundation
>> member assumption.  However I think the Dev<->Staff thing should
>> probably be decoupled if one cannot be staff without being a
>> foundation member.
>
> [...] two different pools of voters (Foundation members and
> "Developers" (which today includes anybody with an @g.o address even
> if they don't have commit access - the proposal splits that into Staff
> and Developers)


By definition #1, if you're a dev then you're staff; staff is a
superset of dev but there's no separation there based on the
definitions listed.  There needs to be a classification for
non-staff-dev if a dev loses foundation membership due to the
staff<->foundation hard coupling and whatever rules there are that
revokes foundation membership and therefore staff status, but can
still remain a dev.

OR, don't couple dev to staff so that devs have a different (sub)set
of rules regarding foundation membership revocation.



> If we want to rationalize the leadership, we also need to deal with
> their constituencies.
>
> Let's take for example the case of somebody booted as a Dev because of
> some CoC violation.  For the sake of simplicity let's assume it was an
> open-and-shut case perfectly handled and Comrel worked in a manner all
> would agree with.  Under our current model, they would stop being a
> dev and might be banned from IRC/etc.  However, they can still vote
> for Trustees.  Does that really make sense?  Likewise, if somebody
> leaves due to inactivity but keeps voting in Trustee elections, they
> also can remain part of the Foundation indefinitely.
>
> I'm sure our "alumni" in general care about Gentoo, but the reality is
> that they don't really have much involvement in the day-to-day.  Do we
> want them picking our leaders/etc?  Today the functions of the
> Trustees are more limited, so it hasn't been as large an issue (though
> as has been pointed out, the legal powers of the Trustees are quite
> large and even if they wisely choose not to exercise them carelessly
> we should certainly exercise care with who we trust in this role).
> However, if we want to expand their powers in practice (setting aside
> whether they already have them legally) then we should probably think
> about who they answer to.  Suppose we did come up with a new Comrel
> GLEP and decided to put it up to a general vote for approval; right
> now we need to figure out which of the two groups of constituents to
> poll.
>
> I don't think we need to add a lot of bureaucracy in practice to make
> this work.  In general anybody qualified to be a dev is already
> qualified to be a Foundation member, even if we make them apply for it
> currently.  While we don't automatically boot people who aren't devs I
> don't see why this would become a problem if the Foundation is
> overseeing the processes by which people leave anyway.
>
> The only real administrative burden it would place on devs is the
> requirements to vote for a Trustee at least once every two years.  I'm
> all ears if somebody has a way to make that go away.  The practical
> issue here is the need to have a quorum under New Mexico law, so if we
> get low turnout the election may not be valid.  While this hasn't come
> up, there is another benefit to making the pool of foundation members
> both large and reasonably active: it makes any kind of "hostile
> takeover" much harder to pull off, while actually making a "good
> takeover" easier.  If some kind of outsider wants to infiltrate they
> need to get a quorum to show up to a meeting and control a majority of
> votes there, and that is harder when there are more members required
> to constitute a quorum.  On the other hand, if somehow things get out
> of control and the community needs to take things back, then not
> having deadwood in the voting rolls means that those who are actively
> involved would find it easier to constitute a quorum at such a
> meeting.  Really, you just want the legal representation of the
> organization to match those who are actively a part of it.
>
> So, the question becomes is compulsory voting a reasonable price to
> pay for better governance.  In some (but not many) countries they feel
> strongly enough about such things that they actually fine you for
> failing to vote.
>
> If we just maintain the status quo across the board I can see less
> urgency here.  However, if we're going to go so far as to consider
> putting the Trustees at the top of the food chain wouldn't it make
> sense to also take a look at how they get elected?  And why would we
> want them maintaining multiple sets of criteria and admission
> processes for the two groups of members they'd now administer?
>
> All that said, this should also demonstrate that "re-organizing"
> Gentoo isn't really just as simple as changing a word in the Wiki
> about where Comrel appeals go.  There are a multitude of concerns that
> need to be dealt with.
>


OK so my issue is that the proposal as i've read it so far (which to
be fair is only a dozen or so posts in the backlog) seems to say that
the relationship goes the other way around from what you've described
above -- in what you say above it seems that the idea here is to allow
for foundation members to be a subset of dev's but also include staff,
and be more limiting.  However it seems to me that devs are a complete
subset of staff in the proposal and therefore any change in foundation
member (and therefore staff) status automatically affects dev status,
or at least that this is an undefined state.

I don't really have an opinion of what it is that's attempting to be
achieved by the changes (at least, not yet), so long as the text makes
it clear what the classifications are and there isn't any ambiguity
between how a change in state of one classification affects another.