[gentoo-dev] Re: Policy regarding the inactive members

[Duncan <1i5t5.duncan@cox.net>]

Matti Bickel posted on Sun, 11 Apr 2010 16:04:57 +0200 as excerpted:

>> A council member is inactive when:
>> 
>> 1) He is inactive in critical discussions ( such as the whole Phoenix
>> discussion ) for a certain period of time
> 
> Please, no. Or we start to get -council/-dev threads about why a certain
> thread here is not considered critical by half of the council when they
> don't reply. If you can't put a number on it, please don't make it a
> hard requirement.

Agreed.  I just don't see how this is can be practically enforced.  Even 
if it's possible to cleanly determine what threads apply, do we really 
want council members posting the equivalent of "discussion-present" 
messages?  Does failure to post when someone else said it better, or even 
just said it already, indicate inactivity?

>> 2) Fails to accomplish his role by supervising the Gentoo projects.
> 
> This isn't even in their domain. I would complain *loud* about any
> council member interfering with projects unless it's an inter-project
> issue. The council is meant for arbitration and vision, not for
> commanding devs.

I believe this was, in fact, specifically one of the reasons the purpose 
was worded as it was, "global issues and policies that affect multiple 
projects".  Even if it was humanly possible for council to micro-manage, 
should it?  Projects and their leaders (and many participants) wanted the 
flexibility and freedom to make their own decisions, not have council 
constantly second-guessing them.

Instead, the wording is deliberately limiting to global Gentoo and inter-
project issues, tho it can be noted that there remains in effect a way for 
council to act in the affairs of an individual project, should it be 
deemed necessary, by declaring the issue to have escalated to enough 
importance that it's now a global Gentoo issue.  So there's a means of 
escalation should it be necessary, and it's the council that makes that 
judgment, subject only to reelection votes, but if it's clearly getting 
out of hand, people will walk and form a new "genthree", if it comes to it.

....

But an issue that I've wondered about before, that I've never seen 
addressed, is this:  With default-monthly meetings and council serving 
only a year, that's only 12 meetings.  A council member could make every 
other one, skipping the last three in a row, and effectively the only 
thing that could be done would be not reelect him.

Now people are human, get sick, have loved ones die, have an earthquake 
hit the day of the council meeting, whatever, so there's gotta be some 
give.

But it always seemed to me that a rolling 2 out of 3 should be required, 
possibly with a council-can-forgive-one-absence clause.  So if you miss 
one, you better make the next two or you're forced to appeal to the "at 
the mercy of the council" clause.  And you can only use that council-mercy 
vote once, so if it happens again, you're out, period.

Also, there needs to be a way for an accelerated new election, should it 
be needed, as otherwise, by 8 months in, by the time the machinery gets 
going, the new councilor might get in for the last meeting, when 
presumably the old council is only finishing up tail-ends.  Is it even 
worth it?  But that's really a topic for another (sub?)thread.

Another alternative would be to make the terms a bit longer, perhaps 18 
months or two years, having half the council replaced every 9 months or 
annually.  Or make it 14 months and stagger terms starting every two 
months.  The idea being, it's never "the last couple months" for 
everyone.  And if the terms are staggered every two months, elections 
would be basically constant, they wouldn't be such a big deal, and council 
policy changes would be more gradual.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman