1 |
On 10/13/2016 11:56 AM, Rich Freeman wrote: |
2 |
> On Thu, Oct 13, 2016 at 12:35 PM, Matthew Thode |
3 |
> <prometheanfire@g.o> wrote: |
4 |
>> Current bylaws state that to become a member you need to petition the |
5 |
>> trustees for membership to the foundation. What verification is done by |
6 |
>> trustees is up in the air. Members also seem to be members for life |
7 |
>> unless they remove themselves are are removed by a vote of the trustees. |
8 |
>> |
9 |
>> I suggest we use and/or modify the existing staff quiz for use as a |
10 |
>> guide for who to admit, as 'graded' by trustees. I also suggest that |
11 |
>> some for of positive acknowledgement that they will adhere to the CoC |
12 |
>> would be helpful as well. |
13 |
> |
14 |
> We've already talked via IM, but some principles I have which probably |
15 |
> are worth just airing are: |
16 |
> |
17 |
> We should have one standard for people who are "part of Gentoo." |
18 |
> Let's call them "staff" for the sake of argument. Staff may or may |
19 |
> not commit to the tree (which is why I didn't use the term devs, |
20 |
> though I realize in practice we tend to use the two terms |
21 |
> interchangeably today). However, they should be active contributors, |
22 |
> and there should be some kind of way of cleaning up people who aren't |
23 |
> active (the bar need not be super high). |
24 |
> |
25 |
> Staff should be expected to adhere to the CoC, and should be all |
26 |
> subject to the same enforcement of it. Staff should be automatically |
27 |
> members of the Foundation, and cease to be Foundation members when |
28 |
> they are no longer staff. The Foundation should of course have a say |
29 |
> in the criteria for admission/removal as a result. However, if we |
30 |
> want to be "one Gentoo" and stop being a "two headed monster" we need |
31 |
> to stop having multiple sets of criteria for how is and isn't a |
32 |
> member/voter/etc. |
33 |
> |
34 |
> Developers with commit access are a subset of staff, and their commit |
35 |
> activity is subject to QA. Staff who aren't developers are generally |
36 |
> not in the scope of QA. |
37 |
> |
38 |
> There will need to be some teams responsible for administering people |
39 |
> getting in, and leaving (whether by inactivity, choice, or forcibly). |
40 |
> There will need to be a governance body with the final say in this. |
41 |
> |
42 |
> I think if you start from this set of principles and work the rest |
43 |
> out, you're a lot more likely to end up with something that isn't a |
44 |
> two-headed beast. You have one constituency, which is the start to |
45 |
> having a more unified leadership structure. I don't think that this |
46 |
> addresses all the issues (not by a long shot), but having just one set |
47 |
> of members and standards and enforcement of those standards is |
48 |
> probably a necessary part of any solution. |
49 |
> |
50 |
All in all fair points. What do we do with developers who are |
51 |
legitimately held up in RL affairs and have appropriately indicated so |
52 |
in devaway? Consensus seems to hold that 6-9 months of inactivity could |
53 |
be enough to invoke Undertaker action. Should that happen and a |
54 |
developer come back, would they need to pass the ebuild tests again, or |
55 |
merely talk to infra to get their account "unlocked" so to speak? |
56 |
|
57 |
I ask because I can think of a few developers who aren't too active, but |
58 |
I don't feel their dev status should be revoked for inactivity -- |
59 |
especially if said inactivity is not something within their (easy) |
60 |
control, like the birth of a child, crunch time at work, and so on. |
61 |
|
62 |
But I see the need to keep Gentoo not only clean, but secure. Automatic |
63 |
'locking' of an account after 6 months or something could help diminish |
64 |
the attack surface of infra, and is easily reversible. |
65 |
|
66 |
-- |
67 |
Daniel Campbell - Gentoo Developer |
68 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
69 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |