From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1ML41P-00074n-Sy for garchives@archives.gentoo.org; Sun, 28 Jun 2009 23:42:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5EBB8E076D; Sun, 28 Jun 2009 23:42:54 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 21CE7E076D for ; Sun, 28 Jun 2009 23:42:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id C10286502F for ; Sun, 28 Jun 2009 23:42:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 required=5.5 tests=[AWL=0.624, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SZWyB5CWNbh for ; Sun, 28 Jun 2009 23:42:47 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id D38B765736 for ; Sun, 28 Jun 2009 23:42:43 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ML41B-0006Ma-FG for gentoo-dev@gentoo.org; Sun, 28 Jun 2009 23:42:41 +0000 Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jun 2009 23:42:41 +0000 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jun 2009 23:42:41 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: 2009 Council Elections Date: Sun, 28 Jun 2009 23:42:31 +0000 (UTC) Message-ID: References: <1246179604.19613.155.camel@localhost> <1246203606.3656.1@NeddySeagoon> <20090628221421.1c9f82c7@anaconda.krait.us> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d743e54e-1209-428f-9c04-dc7d13030b05 X-Archives-Hash: 8c6ca64b5511c49bc8292649d314496c Ferris McCormick posted 20090628221421.1c9f82c7@anaconda.krait.us, excerpted below, on Sun, 28 Jun 2009 22:14:21 +0000: >> Its my opinion that the concept of proxies in council meetings is >> fatally flawed. >>=20 >> 1. The brief (if any) that the proxy is given by the council member >> being proxied is never made public. >>=20 > This is a problem. Any time a council member requires a proxy, that > should be published immediately (including who the proxy is). Not > possible for things coming up at the last minute, of course. Extending that, what about having, at least for a first proxy level, a=20 "designated proxy"? Each council member would choose a proxy at the=20 beginning of their term, or even as a running mate if taken that far. =20 Designated proxies would then be effectively council members with=20 observer status -- no voting power -- unless their designated member was=20 absent. Following the logic, designated proxies /could/ (IOW, I'm not sure it is=20 practical to take it this far) be held to the same general council=20 standards, slacker marks for non-attendance, etc, and in otherwise=20 comment-closed sessions would have voice -- they just wouldn't have the=20 vote unless their designated voting council member was absent. =20 If the proxy was chosen at the beginning of the term (not as a running=20 mate), the first order of business of the first meeting of a new council=20 would be approving the table of proxies. Either way, it would basically=20 eliminate the question of whether a council member or designated proxy=20 must be a dev or not, because either they'd have been voted in with that=20 taken into account, or the council would have approved the designated=20 proxies at the first meeting. (I'd suggest, for fairness and efficiency,= =20 the first approval vote be held on the entire table of proxies, not=20 individually. If that vote fails, then go the individual route. I'm not= =20 sure about what to do if a voting member doesn't make the first meeting;=20 perhaps give the presumed proxy the vote for that first meeting, even if=20 it means he's voting on approving himself?) Now, practically speaking, if this is instituted, since we'd be=20 effectively doubling the number of people on council (just not the number= =20 of votes), it may be useful to reduce the number of voting members a=20 bit. It would in fact be possible to have it an even number, as well, in= =20 which case, if there was a tie, the designated proxies could vote as=20 well, with their combined votes taken as a single tie override. (If the=20 number of voting members were even, however, so would be the number of=20 proxies, thus leading to the possibility of a tie vote there as well. =20 I'd suggest that a wise policy in that case would be that the matter is=20 voted down, as there's simply not enough consensus on the matter yet. If= =20 desired, the issue could be brought up again in say... six months, thus=20 giving each council two chances at a vote, without locking it up on the=20 same issue for months at a time. Alternatively, the first runner(s)-up=20 could be the tie-breaker, and they'd need observer status as well, in=20 ordered to be in the loop enough to cast that vote.) FWIW, it's seven council members now. Perhaps five would work, yielding=20 ten, with the designated proxies as observers. Even four, using the tie=20 breaking rules above, making it 8 including designated proxies. I'd hate= =20 to see it go below four as that gets too easy for abuse, but 4-5 should=20 work. Now if the running mate idea was implemented, there'd be another option=20 as well. Gentoo could continue the policy of runner-up taking the=20 vacancy if one opens (and the runner-up isn't reopen_nominations), or it=20 could switch to the designated proxy aka running mate taking the=20 position. Of course, in the latter case, the running mate would now need= =20 to select a proxy, which would then be handled using the approval process= =20 mentioned above. (In the former case, the runner-up would have already=20 had a running mate.) If the running mates idea is chosen, a rule could be instituted that=20 there's no person appearing at both voting member and running mate (on=20 another ticket), or it could be that a first person on one ticket could=20 be the running mate on another, but a person could only appear once in=20 each spot. (The latter would presumably end up with pair-tickets, where=20 the top person switches off, tho that wouldn't be a given. In the case=20 of pair-tickets, choosing the one would automatically eliminate the other= =20 from further consideration, thereby eliminating the case of two voting=20 council members being each others designated proxy, as well. All this would eliminate the question of whether proxies are up to speed=20 on a given issue, or the briefing they had been given, etc, at least for=20 the first level of proxy, which would now be observer members unless=20 their primary was absent, with the usual expectation and obligation of=20 council members to follow the issues brought before the council. Of=20 course, it would increase the chance of both primary voting member and=20 designated proxy being unavailable, but that could be handled with=20 basically the system we have today, with the additional minimal=20 requirement that non-designated proxies be Gentoo developers in good=20 standing, as they wouldn't have gone thru the vote or approval process. As a new council term is just now starting, obviously the running mate=20 idea couldn't be used this year. However, council members could still=20 choose a designated proxy for the year, thus starting the process. If=20 all council members do so and the council chooses to vote on the table of= =20 proxies, then there should be no restriction on who is chosen, since=20 they'll be voted on anyway. If the council as a whole does not choose to= =20 go the designated proxy route this year, maintaining the status quo, then= =20 I'd say it's unfair to choose a non-dev as a proxy, because there has=20 been no vote approving it. (That would seem to be, after all, the reason= =20 the council members as devs restriction wasn't in GLEP 39, because they'd= =20 have been voted in, and presumably, if the voters, who /are/ devs, voted=20 in a non-dev, they'd know what they were doing. Since under the current=20 system there's no such approval required for proxies, I'd say it's only=20 fair that they be required to be devs, thus minimizing any controversy=20 over their status, and votes they may take.) --=20 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