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

[Rich Freeman]

On Fri, Oct 14, 2016 at 10:17 AM, Ian Stakenvicius <axs@g.o> wrote:
> On 14/10/16 08:43 AM, Rich Freeman wrote:
>>
>> [...] 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.

My intent is that anybody who ceases to be a Foundation member also
loses membership in staff, dev, and loses commit access.

Again, the point is to keep Foundation membership strictly in-line
with what are currently today developers.  This means that the same
people who vote for Council also vote for the Trustees.  (Today staff
are also considered developers and do vote for the Council.)

> 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.

The sets of foundation members and staff are identical.  The set of
developers is a subset of staff.  Anything that causes you to lose
staff causes you to lose developer status.

>
> 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.
>

Perhaps the explanation can use cleanup/etc.

The bottom line is to try to align the various constituencies.

I don't think the names of the groups matter a whole lot as long as
only active contributors are voting for Trustees, and if there is a
separate Council/Trustee election then the same people are voting for
both.

-- 
Rich