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) |