danyc0 / society-voting-bot Goto Github PK

Display the result in #voting channel before sending the "voting has ended" messages to voters. This is because it takes a long time to send such messages, and it delays the whole election whilst we wait for the results. This may not be necessary depending on the outcome of #17

Allow members to change/re-submit their ballot. A possible (and not very well thought through) solution could be to store an anonymised token alongside the ballot. This token would be a hash of their Discord user ID and a password. The password could either be submitted by them, or by the system depending on the level of security needed. This will also need to leverage the list of members that have voted, which already exists.
When the member goes to submit, they must provide the password, which leads to one of 3 cases:

1. If they haven't voted - This is their first vote, so add the token + ballot.
2. If they've already voted and the token already exists - Update the vote.
3. If they've already voted and the token doesn't exist - The submitted password is incorrect.

It may be necessary to rate limit the re-submission attempts, or give a number of possible attempts, in order to prevent brute-force. Another approach would just be to enforce having a password with enough entropy that it's infeasible to brute-force it.

Fix layout of README, it's very hard to read at the moment

Committee members should be able to rename posts

Fix Google OAuth so that it can:
A. Generate tokens on the server, and
B. Refresh the token as needed

Allow the blocks of text sent after registering/standing/other things to be configured

This would include removing references to "CSS", probably making that a value in the config file

Consider having a unique voting code for each post. This would add complexity to the procedure, but would ensure that if someone joins for the first 5 minutes, then leaves, that they cannot continue to vote.

Move command prefix (currently '') into the config file

This will likely be a lot of work, in the meantime each instance should only be in one guild/server, but multiple instances can be run on the same machine

Expand the automated message sent when people stand to say that:

• They will need to prepare a 2 minute speech.
• If they have any questions to contact the secretary (configurable), or someone else on the committee.
• If they can't make it to the actual call, tell them to get in touch with the secretary ASAP to sort alternative arrangements

Allow committee members to stand people down, for use in cases where someone accidentally stands for a post that they are ineligible to stand for (like if a non-PGT stand for PGT rep)

Currently this is implemented as if they didn't turn up. The complication of doing the former option is how can you tell the difference between someone that didn't vote because they wanted to abstain, and didn't vote because they didn't turn up to the election and therefore don't know the voting code

When someone stands for a post, add their details (name, email, student number and the post they are standing for) to a google sheet that is only accessible to the committee.
It's important that this happens relatively quickly (ideally <2 minutes) as this may happen during the election call as people stand from the floor.

Find a proper fix for #17 instead of just adding a sleep. Possibly create a task for the sending of the messages?

When someone stands for a post, email the secretary with their name, email (this currently isn't collected), student number and the post they are standing for.
It's important that this email arrives relatively quickly (ideally <2 minutes) as this may happen during the election call as people stand from the floor.

The changes required will include:

• A separate listing from the standard posts
• A command for committee members to create them (similar to \setup, or a adjustment to it)
• Default "Candidates" created of "Yes" and "No" for each one on setup
• A restriction to stop members from standing as candidates

Possible cogs could be Admin (create posts, begin/end voting, etc), Info(list posts/candidates/referenda, display the rules) and Voting (DM only, submit/validate)

Things like:

• Emailing the secretary
• Adding stuff to the google sheet
• Voting codes
• The existence of RON (Re-Open Nominations)

Consider moving most config settings into a config file separate from .env. Only leaving secret things like the discord token and channel IDs in the .env

A number of the current checks can be replaced with built-in command checks and the rest should be converted into command checks

There needs to be better documentation of the usage of all the commands, who can use them, and where they can be used. This should probably be in the help text

End the voting automatically if all the voting has been cast (this could be an optional feature)

This info is already output to the logs, but it would be useful in committee general. This should only be done if the bot can edit the post with the information, otherwise it will produce far too much spam

There can sometimes be race conditions between reads and writes of certain shared resources like current_live_post

Committee members should be able to delete posts. A warning may be necessary to ensure posts aren't deleted if people are already standing for it. Or maybe just those standing for it should be messaged saying it's been deleted?

Both for general satisfaction and from an inclusivity point of view, we should allow candidates' names to be changed. This could either be through a committee action or the candidates themselves

Support new voting style such that people standing for posts lower down the running order can still stand for other posts if they do not get elected to their desired post.

As things stand, if people stand for a post near the top of the running order, but do not get it, they can stand for a later post from the floor. This is a very good thing, but is not available to those standing for posts near the end of the running order as there are no more posts left for them to stand for from the floor.

One proposal to fix this would be:

1. Everybody stands for all posts which they even have any sort of desire to run for
2. All voting happens without revealing the results
3. Announce which people won more than one post
4. Let those candidates pick which one they want to keep
5. Re-run the IRV voting calculations on the ballot papers for the posts that were not chosen, as if that candidate did not stand in the first place (no more voting has to happen, as this can be calculated from the original ballot papers)
6. Repeat 5 until no more candidates hold more than one role

The issues I can see here are that:
A. people in this scenario will often stand from the floor for posts which have 0/few candidates, which is unknown at the point they are standing (maybe this could be bypassed by candidates registering in advance, publically, what their preferences are for the post they want to hold, but this might amplify issue C.
B. This could result in each role having a huge number of candidates
C. This could bias people's voting as they may not want to vote for a candidate for more than one post (for example: "well I voted for person X for the president, so I won't vote for them for secretary"). This could maybe be mitigated by making this possibility very clear and educating people on not doing it.
D. The order in which the IRV is re-run could impact the results, as those who get their IRV re-run first are more likely to get their first choice of post. Maybe this order could re randomised to avoid this?

The simplest way to do this is to outline in documentation that in adverts for the election, those who cannot access the Discord must contact the secretary/committee to arrange either an alternative way to vote, or better yet, to find a way for them to access the Discord (possibly through the SoCS VPN)

Voting should be restricted to only those in the live election call. A possible way to implement this would be to have a simple password which is given out during the call, without which you cannot vote.

Allow some sort of \beginnext which begins the next post in the running order. This relies on #23 being implemented first, so ensure the order is correct.
This is helpful because when running the bot, it is hard to keep track of what's next, and getting the exact spelling/phrasing of the post is a pain

Keep track of which posts have been voted upon so that it's easy to see which ones are left to come. This might be part of #24

Break the implementation of get_members into a seperate file for users to configure. Leave the standard UoB example in there, but allow people to change the implementation to scrape their own union website. It could also be used to support reading the member lists from a file instead.

This should be an optional feature

Decide what happens if you register to vote whilst voting is going on for a post, should you be sent a ballot paper?

When referring to a user, it should be output with their name, student number and discord username. At the moment it's very unstandardised, in some places it uses one/two of the three, but rarely all three

This is related to #15

This will require some research and experience of async

Consider sending the rules/instructions when the first post is voted upon, as there might be a large time gap between registering (when they are currently sent), and the election. It's also not hugely clear if the info sent on registering is only for those planning to stand for posts

Document (probably in the README), the permissions that the bot requires

Consider a setting to allow all ballot papers to be sent at once, then all voting happens, then all ballots are submitted at once.
This has its advantages (speed) and disadvantages (people may forget what they thought of candidates' speeches, etc for the early posts by the time they have all happened)

At the moment it's just the order in which they were \setup with the bot (\rename also moves a post to the bottom). It would be nice if this were fixed so that it is easy to see the voting order

List the discord usernames of candidates alongside their names, so "Dan Clark" should be something like "Dan Clark - danyc0"

Lots of unrecognised commands are received due to typos, etc, and having a custom error handler which responds explaining that the command was not recognised would be good