Gentoo Archives: gentoo-nfp

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Cc: gentoo-nfp <gentoo-nfp@l.g.o>
Subject: [gentoo-nfp] Re: [gentoo-project] Foundation membership and who can join
Date: Thu, 13 Oct 2016 18:56:16
Message-Id: CAGfcS_nq4gpw=dxW=Z84vRYf-42N0_wOi=mjF5X6knEms2gtWA@mail.gmail.com
In Reply to: [gentoo-nfp] Foundation membership and who can join by Matthew Thode
1 On Thu, Oct 13, 2016 at 12:35 PM, Matthew Thode
2 <prometheanfire@g.o> wrote:
3 > Current bylaws state that to become a member you need to petition the
4 > trustees for membership to the foundation. What verification is done by
5 > trustees is up in the air. Members also seem to be members for life
6 > unless they remove themselves are are removed by a vote of the trustees.
7 >
8 > I suggest we use and/or modify the existing staff quiz for use as a
9 > guide for who to admit, as 'graded' by trustees. I also suggest that
10 > some for of positive acknowledgement that they will adhere to the CoC
11 > would be helpful as well.
12
13 We've already talked via IM, but some principles I have which probably
14 are worth just airing are:
15
16 We should have one standard for people who are "part of Gentoo."
17 Let's call them "staff" for the sake of argument. Staff may or may
18 not commit to the tree (which is why I didn't use the term devs,
19 though I realize in practice we tend to use the two terms
20 interchangeably today). However, they should be active contributors,
21 and there should be some kind of way of cleaning up people who aren't
22 active (the bar need not be super high).
23
24 Staff should be expected to adhere to the CoC, and should be all
25 subject to the same enforcement of it. Staff should be automatically
26 members of the Foundation, and cease to be Foundation members when
27 they are no longer staff. The Foundation should of course have a say
28 in the criteria for admission/removal as a result. However, if we
29 want to be "one Gentoo" and stop being a "two headed monster" we need
30 to stop having multiple sets of criteria for how is and isn't a
31 member/voter/etc.
32
33 Developers with commit access are a subset of staff, and their commit
34 activity is subject to QA. Staff who aren't developers are generally
35 not in the scope of QA.
36
37 There will need to be some teams responsible for administering people
38 getting in, and leaving (whether by inactivity, choice, or forcibly).
39 There will need to be a governance body with the final say in this.
40
41 I think if you start from this set of principles and work the rest
42 out, you're a lot more likely to end up with something that isn't a
43 two-headed beast. You have one constituency, which is the start to
44 having a more unified leadership structure. I don't think that this
45 addresses all the issues (not by a long shot), but having just one set
46 of members and standards and enforcement of those standards is
47 probably a necessary part of any solution.
48
49 --
50 Rich