Hi, everyone.

I've collected a few ideas for improving elections in Gentoo over time,
and I think they reached a critical mass when they would even justify
rewriting votify.  Since those ideas need time both for implementation
and for testing, I'd like to start early discussion now, so maybe we'd
be able to actually bring them for the next year's elections.


The problems
============
Here's a short list of problems I've identified with the current
scripting.  I'm not saying they're all major problems but I believe we
can improve.

1. It's vaporware.  I know it's less vaporware than e.g. Devotee used by
Debian which didn't even work with modern Perl last I checked (~a year
ago) but still.  It's unloved, spews undefined reference warnings
at runtime and it's Perl.

2. It's not that convenient to use, especially for infra side
of elections.  I mean, it's not really horrible but it's easy to get
wrong, file formats are rather opaque, it relies on hardcoded paths
and in the end there's a lot of manual work that needs to be done.

3. Due to the above, it doesn't encourage voters to verify election
results.  I'm hoping to improve this with Votrify but it's painful to
integrate anything into votify.

4. It doesn't protect voter privacy properly.  While the election is
running, anyone in Infra can trivially look at the votes in home
directories.  We even had one case of election official accidentally
leaking the voter mapping.

5. It doesn't really account for votes of non-developers (in Trustee
elections).  We hack them in.

6. It doesn't cover the nomination phase at all.  Right now this implies
some wiki handiwork, that's afterwards converted into votify handiwork. 
There's space for improvement.


My ideas
========
While improving the scripts, I'd like to include the following ideas:


1. The system should be privacy-oriented.  We don't really need to store
dev-confirmation id mapping permanently or keep votes explicitly linked
to devs.

Instead, I'd like to replace it with a longer 'secret token' that's
generated at the start of election, then KDF-ed into 'public token'. 
Both are encrypted to the dev in question, secret token is afterwards
discarded and public token is used to identify the vote.

Votes wouldn't be kept in home directories anymore.  Instead, they would
be copied to dedicated directory with each vote identified only by
'public token', and each developer being able to edit his vote by
providing the respective 'secret token'.


2. Since votes are no longer strictly bound to developer accounts, we
can provide better mechanism for non-developers to vote.  We could go
even as far as to providing a website for it but also a dedicated shell
account on d.g.o would also work.


3. UI could use an improvement, both from user and election official
perspective.  I'd like the tool to be clearly separated into reusable
components, and transparent enough for anyone to be able to easily
verify election results.  I'd also like to minimize the amount of work
election officials need to do.


4. I'd like the tooling to be usable not only for the big deals
(Council, Trustee) elections but also let regular developers start
project lead elections and any other kind of voting they need.


5. Far future idea: I'd like to replace election officials (no offense
intended) with community verification of votes.  Basically, rather than
having m people (with small 'm') count votes independently, I'd like to
have n people (ideally, with n >= 75% voters) both count votes
and verify that their own vote is included.


This last point I'm already testing with Votrify [1] and it can be
considered independently of the rest.  Technically also first two could
be implemented without changing votify core but it's going to become
more and more of a patchwork.

What are your thoughts?

-- 
Best regards,
Michał Górny