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

[Raymond Jennings]

That's why I made my own proposal.

class supporter
{
    string name;
    string email;
    set<string> project_memberships;
    bool is_foundation_member;
    bool agreed_to_coc;
public:
    supporter()
    {
        agree_to_coc()
    };
    virtual ~supporter()
    {
        // violated CoC
        revoke_access_to_portage_tree();
        revoke_access_to_staff_areas();
        revoke_foundation_membership();
    }
};

class developer: virtual public class supporter
{
    set<string> projects_maintained;
public:
    developer(const mentor *m, const recruiter *r)
    {
        pass_ebuild_quiz();
        pass_end_quiz();
        m->file_dev_bug();
        r->receive_quizzes();
        r->interview_developer(this);
        grant_access_to_portage_tree();
    };
};

class staff: virtual public class supporter
{
public:
    staff()
    {
        pass_staff_quiz();
        grant_access(); // irc, forums, ml, bugzilla, infra, etc etc etc
    };
};

class foundationmember: virtual public class supporter
{
public:
    foundationmember()
    {
        foundation::trustees.approve(this);
    };
};

And of course people could occupy more than one such "derived" role at the
same time, but all three roles have the baseline of being a 'supporter"
that at a minimum requres agreement to, and compliance with, the CoC.

Thoughts?

On Fri, Oct 14, 2016 at 5:43 AM, Rich Freeman <rich0@g.o> 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.
>
> I disagree.  Let me explain why I am suggesting making the various
> groups tightly bound:
>
> One of the problems we have with the current organizational model is
> that we have 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)).  They each elect a set of leaders, which differing
> areas of responsibility (but also with some degree of overlap, since
> the Foundation has a mission bigger than keeping the lights on and the
> Council currently oversees Comrel/CoC/etc).
>
> 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.
>
> --
> Rich
>
>