1 |
Hi, everyone. |
2 |
|
3 |
I've collected a few ideas for improving elections in Gentoo over time, |
4 |
and I think they reached a critical mass when they would even justify |
5 |
rewriting votify. Since those ideas need time both for implementation |
6 |
and for testing, I'd like to start early discussion now, so maybe we'd |
7 |
be able to actually bring them for the next year's elections. |
8 |
|
9 |
|
10 |
The problems |
11 |
============ |
12 |
Here's a short list of problems I've identified with the current |
13 |
scripting. I'm not saying they're all major problems but I believe we |
14 |
can improve. |
15 |
|
16 |
1. It's vaporware. I know it's less vaporware than e.g. Devotee used by |
17 |
Debian which didn't even work with modern Perl last I checked (~a year |
18 |
ago) but still. It's unloved, spews undefined reference warnings |
19 |
at runtime and it's Perl. |
20 |
|
21 |
2. It's not that convenient to use, especially for infra side |
22 |
of elections. I mean, it's not really horrible but it's easy to get |
23 |
wrong, file formats are rather opaque, it relies on hardcoded paths |
24 |
and in the end there's a lot of manual work that needs to be done. |
25 |
|
26 |
3. Due to the above, it doesn't encourage voters to verify election |
27 |
results. I'm hoping to improve this with Votrify but it's painful to |
28 |
integrate anything into votify. |
29 |
|
30 |
4. It doesn't protect voter privacy properly. While the election is |
31 |
running, anyone in Infra can trivially look at the votes in home |
32 |
directories. We even had one case of election official accidentally |
33 |
leaking the voter mapping. |
34 |
|
35 |
5. It doesn't really account for votes of non-developers (in Trustee |
36 |
elections). We hack them in. |
37 |
|
38 |
6. It doesn't cover the nomination phase at all. Right now this implies |
39 |
some wiki handiwork, that's afterwards converted into votify handiwork. |
40 |
There's space for improvement. |
41 |
|
42 |
|
43 |
My ideas |
44 |
======== |
45 |
While improving the scripts, I'd like to include the following ideas: |
46 |
|
47 |
|
48 |
1. The system should be privacy-oriented. We don't really need to store |
49 |
dev-confirmation id mapping permanently or keep votes explicitly linked |
50 |
to devs. |
51 |
|
52 |
Instead, I'd like to replace it with a longer 'secret token' that's |
53 |
generated at the start of election, then KDF-ed into 'public token'. |
54 |
Both are encrypted to the dev in question, secret token is afterwards |
55 |
discarded and public token is used to identify the vote. |
56 |
|
57 |
Votes wouldn't be kept in home directories anymore. Instead, they would |
58 |
be copied to dedicated directory with each vote identified only by |
59 |
'public token', and each developer being able to edit his vote by |
60 |
providing the respective 'secret token'. |
61 |
|
62 |
|
63 |
2. Since votes are no longer strictly bound to developer accounts, we |
64 |
can provide better mechanism for non-developers to vote. We could go |
65 |
even as far as to providing a website for it but also a dedicated shell |
66 |
account on d.g.o would also work. |
67 |
|
68 |
|
69 |
3. UI could use an improvement, both from user and election official |
70 |
perspective. I'd like the tool to be clearly separated into reusable |
71 |
components, and transparent enough for anyone to be able to easily |
72 |
verify election results. I'd also like to minimize the amount of work |
73 |
election officials need to do. |
74 |
|
75 |
|
76 |
4. I'd like the tooling to be usable not only for the big deals |
77 |
(Council, Trustee) elections but also let regular developers start |
78 |
project lead elections and any other kind of voting they need. |
79 |
|
80 |
|
81 |
5. Far future idea: I'd like to replace election officials (no offense |
82 |
intended) with community verification of votes. Basically, rather than |
83 |
having m people (with small 'm') count votes independently, I'd like to |
84 |
have n people (ideally, with n >= 75% voters) both count votes |
85 |
and verify that their own vote is included. |
86 |
|
87 |
|
88 |
This last point I'm already testing with Votrify [1] and it can be |
89 |
considered independently of the rest. Technically also first two could |
90 |
be implemented without changing votify core but it's going to become |
91 |
more and more of a patchwork. |
92 |
|
93 |
What are your thoughts? |
94 |
|
95 |
-- |
96 |
Best regards, |
97 |
Michał Górny |