aslakhol
commented
2 years ago What do we need in this document:
There are three major concerns we must address.
-
Votes are secret. How do we ensure that no one, not even us can see what a given person has voted for? Here we could mention that we have decided to not build the option for voting openly so that we avoid many of these problems.
-
All votes are counted. How do we make sure that each vote given is counted? What mechanisms have we included to make sure that we can abort a vote if we don't have all the votes?
-
One vote per person. How do we ensure that one logged-in user gets only one vote? Also, what do we do to ensure that one person only has one user, here we might talk about the tools we have for inviting users, for admins to oversee the user list and other things?
In addition to the three main concerns, we should also talk about how the votes are counted. For this point, I think the information we already have on the page for setting up votations is enough, but it could be interesting to have a link to the GitHub page with the code that tabulates the votes if this is easily available.
We should also have a section outlining our flaws. For this, we should mention that unless the reader is a developer and is interested in reading all the code (which is openly available at ), there will have to be some trust in the developers of this site. However, this trust is always necessary for a vote. Usually, you trust two or three people who count the votes. In the case of vedtatt.no at least you know that our only interest is in creating a fair and easy-to-use voting system, which might not be the case when people are counting your votes.
One other flaw we have compared to voting with notes is that there is a possibility that our systems go down, maybe we should mention this as well?
We need to explain in a relatively simple manner how our technological and design decisions account for the above factors. The document should not be very long, no longer than one page. It should also appear on the website, perhaps under a subheading on the About Us page referred to in #154. Our goal with this text is that those in charge of our meetings can understand in general terms what is going on. We should not get bogged down in too much technical detail. If you want you can imagine the target audience for this text to be the board of a linjeforening in a non-technical field where we assume there are no developers on the board.
It would likely be very helpful if you had friends who have been at a general annual meeting, but who are not developers read the text and provide you with feedback.
Some people are skeptical of digital voting. We need to write a text explaining, in fairly approachable terms which architectural decisions we made, that ensure the security of the system. We do not need to argue that the system can be used for national elections, but we should make the users aware of our strengths and our flaws. It would be very useful to compare our methodology to physical vote counting, as our target audience is organizations that have previously used such systems.
This could live in an about page or some other place where it is visible to the user. It could also be included in the README, but that is not important.