Gentoo Archives: gentoo-nfp

From: "Michał Górny" <mgorny@g.o>
To: gentoo-nfp@l.g.o
Subject: Re: [gentoo-nfp] [RFC] Alternative methods for determining 'interest in Foundation affairs'
Date: Fri, 06 Sep 2019 05:20:38
Message-Id: b06c62191f86721c6bd4f5b11cc752af259ff5c2.camel@gentoo.org
In Reply to: Re: [gentoo-nfp] [RFC] Alternative methods for determining 'interest in Foundation affairs' by "Robin H. Johnson"
1 On Thu, 2019-09-05 at 22:42 +0000, Robin H. Johnson wrote:
2 > If you consider various real world voting systems, they generally
3 > require some form of electoral roll, on which voters are checked off, to
4 > prevent voting multiple times (this can be enforced with other
5 > mechanisms).
6
7 Sure but I should point out that generally:
8
9 1. The people who are checking you off generally try to cover other
10 voters on the list.
11
12 2. They don't have a real way of associating your vote with your check
13 off.
14
15 So I don't think examples of 'real life' voting systems are really
16 relevant, unless they are 100% electronic and are subject to the same
17 inherent weaknesses as we are. However, even then the scale might make
18 sniffing votes impractical.
19
20 >
21 > > > 2. It introduces a big weakness in the system. My whole idea was to
22 > > > make it practically impossible to sniff votes after the election is
23 > > > prepared. With this solution, anyone with sufficient privileges
24 > > > (election officials, infra) can trivially passively sniff votes.
25 > > We need to know who cast votes, we don't need to know the content of the
26 > > votes. I assume building such a system is possible (maybe it isn't?)
27 > mgorny's system design is explicitly around building protections to
28 > enable LESS trust being placed in infra & voting officials.
29 >
30 > Timing correlation in when a vote or stub appears in the system is a
31 > concern in that environment.
32 >
33 > I agree that it should be possible to build this requirement into the
34 > system, but at what cost in development.
35
36 To be honest, I can't really think of a reasonable way to do that. We
37 have simply too few votes spread over too much time.
38
39 > > > I believe we should consider other options of determining activity.
40 > > > Depending on whether we actually want to keep people actually interested
41 > > > in GF, or just those caring enough to stay, I can think of a few
42 > > > options.
43 > I'd say those options should be in addition to, rather than instead of
44 > voting.
45
46 Why? What is the difference, say, between casting a vote and pushing
47 a 'I am active' button once a year? If the latter's an option, there's
48 really no point in leaking voting information just to have two
49 alternatives.
50
51 >
52 > > > Another option (which some people aren't going to like) is to require
53 > > > all Foundation members to be Gentoo devs (but not the other way around),
54 > > > and then terminate GF membership along with developer status. Given
55 > > > that there's only a few non-dev members, and most of them are retired
56 > > > devs whose membership simply didn't terminate by existing rules yet, I
57 > > > think there shouldn't really be a problem in making the few interested
58 > > > members non-commit devs by existing rules.
59 > > This doesn't really imply interested in the Foundation either though;
60 > > because the developership and Foundation are separate.
61 > If this includes making non-commit developership easier to
62 > get AND maintain (the undertaker discussions about how to gauge
63 > ongoing involvement of non-commit devs is very relevant to this), then I
64 > have no conceptual problem with requiring all Foundation members to be
65 > developers (It should still be possible to be a developer WITHOUT being
66 > a Foundation member).
67
68 That is the point. However, we need solid proposals for this.
69
70 --
71 Best regards,
72 Michał Górny

Attachments

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