Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Policy regarding the inactive members
Date: Sun, 11 Apr 2010 15:27:38
In Reply to: Re: [gentoo-dev] Policy regarding the inactive members by Matti Bickel
1 Matti Bickel posted on Sun, 11 Apr 2010 16:04:57 +0200 as excerpted:
3 >> A council member is inactive when:
4 >>
5 >> 1) He is inactive in critical discussions ( such as the whole Phoenix
6 >> discussion ) for a certain period of time
7 >
8 > Please, no. Or we start to get -council/-dev threads about why a certain
9 > thread here is not considered critical by half of the council when they
10 > don't reply. If you can't put a number on it, please don't make it a
11 > hard requirement.
13 Agreed. I just don't see how this is can be practically enforced. Even
14 if it's possible to cleanly determine what threads apply, do we really
15 want council members posting the equivalent of "discussion-present"
16 messages? Does failure to post when someone else said it better, or even
17 just said it already, indicate inactivity?
19 >> 2) Fails to accomplish his role by supervising the Gentoo projects.
20 >
21 > This isn't even in their domain. I would complain *loud* about any
22 > council member interfering with projects unless it's an inter-project
23 > issue. The council is meant for arbitration and vision, not for
24 > commanding devs.
26 I believe this was, in fact, specifically one of the reasons the purpose
27 was worded as it was, "global issues and policies that affect multiple
28 projects". Even if it was humanly possible for council to micro-manage,
29 should it? Projects and their leaders (and many participants) wanted the
30 flexibility and freedom to make their own decisions, not have council
31 constantly second-guessing them.
33 Instead, the wording is deliberately limiting to global Gentoo and inter-
34 project issues, tho it can be noted that there remains in effect a way for
35 council to act in the affairs of an individual project, should it be
36 deemed necessary, by declaring the issue to have escalated to enough
37 importance that it's now a global Gentoo issue. So there's a means of
38 escalation should it be necessary, and it's the council that makes that
39 judgment, subject only to reelection votes, but if it's clearly getting
40 out of hand, people will walk and form a new "genthree", if it comes to it.
42 ....
44 But an issue that I've wondered about before, that I've never seen
45 addressed, is this: With default-monthly meetings and council serving
46 only a year, that's only 12 meetings. A council member could make every
47 other one, skipping the last three in a row, and effectively the only
48 thing that could be done would be not reelect him.
50 Now people are human, get sick, have loved ones die, have an earthquake
51 hit the day of the council meeting, whatever, so there's gotta be some
52 give.
54 But it always seemed to me that a rolling 2 out of 3 should be required,
55 possibly with a council-can-forgive-one-absence clause. So if you miss
56 one, you better make the next two or you're forced to appeal to the "at
57 the mercy of the council" clause. And you can only use that council-mercy
58 vote once, so if it happens again, you're out, period.
60 Also, there needs to be a way for an accelerated new election, should it
61 be needed, as otherwise, by 8 months in, by the time the machinery gets
62 going, the new councilor might get in for the last meeting, when
63 presumably the old council is only finishing up tail-ends. Is it even
64 worth it? But that's really a topic for another (sub?)thread.
66 Another alternative would be to make the terms a bit longer, perhaps 18
67 months or two years, having half the council replaced every 9 months or
68 annually. Or make it 14 months and stagger terms starting every two
69 months. The idea being, it's never "the last couple months" for
70 everyone. And if the terms are staggered every two months, elections
71 would be basically constant, they wouldn't be such a big deal, and council
72 policy changes would be more gradual.
74 --
75 Duncan - List replies preferred. No HTML msgs.
76 "Every nonfree program has a lord, a master --
77 and if you use the program, he is your master." Richard Stallman