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

[Daniel Campbell]

On 10/14/2016 07:17 AM, Ian Stakenvicius wrote:
> 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.
>
>
+1. I think all anyone involved in this discussion wants is clearer,
fairer standards for all staff+devs+foundation members. And hopefully,
enough introspection to question whether past decisions were correct.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6