Gentoo Archives: gentoo-nfp

From: Ferris McCormick <fmccor@g.o>
To: Roy Bamford <neddyseagoon@g.o>
Cc: gentoo-nfp@l.g.o, trustees@g.o
Subject: Re: [gentoo-nfp] Points to Ponder for Sundays Meeting.
Date: Thu, 17 Apr 2008 18:50:48
Message-Id: 1208458241.408.26.camel@liasis.inforead.com
In Reply to: [gentoo-nfp] Points to Ponder for Sundays Meeting. by Roy Bamford
1 On Thu, 2008-04-17 at 19:15 +0100, Roy Bamford wrote:
2 > -----BEGIN PGP SIGNED MESSAGE-----
3 > Hash: SHA1
4 >
5 > Team,
6 >
7 > 1. We are required to advise Foundation members of meetings, in advance
8 > and it seems, written notice is required. Its my view that an opt in
9 > mailing list like gentoo-nfp is not adequate. Many members don't
10 > subscribe and its also used for public debate, which many members are
11 > not interested in.
12 > I don't think snail mail is in keeping with our image either.
13 >
14 > It follows that we need something like gentoo-foundation-announce which
15 > members are automaticly subscribed to or we use a list of members email
16 > addresses to circulate notices. The difference is one of implementation
17 > detail.
18 >
19
20 I like the idea of gentoo-foundation-announce@. The very fact that I am
21 going to get some number of bounces from gentoo-nfp for nonexistent
22 addresses shows that gentoo-nfp (as it stands) is not adequate.
23
24 > We probably need to agree our bylaws before we can implement such a
25 > list, as the bylaws define the qualifications for membership.
26 >
27 > 2. IRC voting and Proxies.
28 > I'm not sure we will ever use IRC for a vote. It could be managed by
29 > voicing the members on the list in 1) and setting the channel +m. Votes
30 > are then cast, since only members can speak in the channel.
31 >
32 > The voicing will also prove that voting nicks are identified.
33 >
34
35 IRC for voting is impractical for reasons you articulate.
36
37 > If we allow proxies, it gets more complex. We need to voice the proxies
38 > and when we count votes, ensure that the member and proxy cast only a
39 > single vote.
40 >
41 > Its further complicated by a world wide membership. The law says that
42 > to be quorate and make decisions a members meeting needs >10% of the
43 > members entitled to vote on an issue (at the first attempt anyway). A
44 > short voting period on IRC would exclude the half our members who
45 > would be in bed. In reality, we would struggle to make the 10%. There
46 > were less than 40 attendees for our first meeting, when interest in the
47 > Foundation was at its height.
48 >
49 > I'm coming round to the opinion that any issues needing to be put to a
50 > vote of members will be voted on in the normal Gentoo way over a period
51 > of days, if not weeks. If that's so, we need some officers to run
52 > votes.
53 >
54
55 I agree. Then, as I think I suggested previously, the formal vote can
56 be the tellers' report. This is really equivalent to having everyone
57 vote by proxy to the tellers, and the proxy vote is the normal Gentoo
58 vote. Depending on how long it takes to extract a result from the raw
59 Gentoo votes, I suppose we could keep the voting period open for 5
60 minutes into the meeting or some such. Note that members who are not
61 developers already vote "by proxy" --- send a signed ballot to a teller.
62
63 Another question about voting (and one for the bylaws) is how we extract
64 winners. Currently, Gentoo overall uses an iterative Condorcet process
65 until the required number of winners is chosen. Since Condorcet voting
66 chooses only one winner, you have to eliminate the winner from the slate
67 of candidates and run it again over and over until you have the correct
68 number of winners. In "real life" (as in countries) people generally
69 don't do that; instead, they use a method which can choose the required
70 number of winners all at once. The results can be different (e.g.,
71 different methods chose different Councils last year --- I know, I tried
72 it.)
73
74 {{{ I am not necessarily advocating change; what we do works well
75 enough. I am mentioning possibilities. And by the way, once you have
76 many candidates and possibly many winners, NO method is perfect ---
77 e.g., a rank-the-candidates procedure can give completely different
78 results from a choose-the-ones-you-want rule. See Donald G Saari
79 generally (most recently, Notices of the AMS, v55 #4 (April, 2008) pp
80 448--455 & accompanying references. }}}
81
82 > I'm just trying to air my views in advance of the Sunday meeting in the
83 > hope it will make the meeting slicker.
84 >
85 > Thoughts and other options please.
86 >
87 > - --
88 > Regards,
89 >
90 > Roy Bamford
91 > (NeddySeagoon) a member of
92 > gentoo-ops
93 > forum-mods
94 > treecleaners
95 > trustees
96 > -----BEGIN PGP SIGNATURE-----
97 > Version: GnuPG v2.0.9 (GNU/Linux)
98 >
99 > iEYEARECAAYFAkgHk84ACgkQTE4/y7nJvaslpACeIPl+nPMN6PR17/+x8cTgJZK7
100 > BKUAoM50PAhkuK4SfPZawk71K1R9Styb
101 > =Uhcf
102 > -----END PGP SIGNATURE-----
103 Adding to the complexity,
104 Regards,
105 Ferris
106 --
107 Ferris McCormick (P44646, MI) <fmccor@g.o>
108 Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)

Attachments

File name MIME type
signature.asc application/pgp-signature