Add a /vote command

[natemoo-re]

We have a well-documented governance process for nominating new members as maintainers/core maintainers for Astro.

These nominations happen in a new thread in the #core or #maintainers channel.

Unfortunately, as the team grows, manually tallying votes becomes increasingly difficult. The process involves hunting down a list of all the currently active maintainers + core, removing any core-in-residency members (no voting privileges), then cross-checking all of the responses to verify that you've correctly recorded everyone's response.

As such, I've been tracking recent nominations in a separate spreadsheet. It'd be nice to have a new /vote command that creates an embed for users to click "Yes / No / Abstain". When a button is pressed, the bot could update an anonymous tally in whatever db we end up using and reply in the thread with the number of votes remaining.

I'm sure there could be further automations in the future, but that seems like a good starting place.

[wassfila]

• This is something that will require us to have a full fledged testing infrastructure, where we can have multiple users (at least 5) have access and run tests
• We will need to have a clear vote update mechanism, and define if vote can keep being updated till last minute, which seems to be the case at the moment, so it should not be restricted by this.
• Important to define if votes are public or secret, if it is encouraged to update votes depending on the others, which can get weird sometimes when someone gets in a position to have decisive power in the last minute. I know these are weird corner cases, but I'm thinking from gaming theory perspective how not to deteriorate the voting experience due to new artificial powers. As of now votes seem to be public but the question that remains is do we show voting stats in every voting widget or not ?
• We can elaborate a threat model by defining where the critical aspects of it are and who can access and edit what ? but that's probably something that will be db related, I consider the threat very low in case everyone can verify who voted what on a summary view which allows to check votes count consistency.
• Do we create a dashboard out of this somewhere or leave the thread posted widgets as only source of UI to show the results ?
• Or maybe we add a command that posts a stats summary in case votes have run too high up in the conversation, that could also be a "/closing-vote" command that would then stop the vote mechanism and shows the results, eventually if positive with e.g. confettis.
• and this should support the odd event of running more than one vote in parallel, without mixing up results
• db votes retention policy, and if usernames are hashed in the db, encryption is I would say not necessary for any field.

[mandar1jn]

Although the voting procedure is pretty well documented, I don't feel comfortable commenting on the implementation of something I have never seen in action before. There are some things here I can comment on.

@wassfila mentioned hashing usernames. Usernames are a very naive way to store votes since users are able to modify those. So vote retention should always be based on the user ID. These can be hashed.

As shown by Wasfilla's numerous points, this is definitely a feature that requires a full RFC before being implemented. Especially since this is at the core of how Astro is managed

[wassfila]

@wassfila mentioned hashing usernames. Usernames are a very naive way to store votes since users are able to modify those. So vote retention should always be based on the user ID. These can be hashed.

absolutely, yeah to be very specific it should be what discord considers as unique identifiers for the users, don't know if they have numbers uids but I used that in the Astro-Support-List for me it's the same username wassfila discord id @wassfila

this is definitely a feature that requires a full RFC before being implemented.

so, this is an RFC already, so what you suggest is to have a fully approved specification, which would be consolidating the bullet points I started, the question would only be do we write the final spec here in a new comment or do we need another place like Hackmd which is more stable and easier to find after this gets completed and closed. Or maybe the readme of the repo itself as spec of what is implemented/to be implemented e.g. commands_spec.md.

[mandar1jn]

A fully approved specification is indeed what I meant.

[wassfila]

OK, I see. One way how we can show that an RFC is ready and accepted is by using the states that I created, independent from the specification being within this ticket or provided by a link, only the state of the github issue "RFC_Implementation" shows that the RFC specification is approved and it can proceed to implementation. Now in reality, we will be overlapping the implementation and specification refinement, but we can do this at least for the main functionalities.
I pushed on another ticket the creation of a Houston channel so that we can speed up the discussions to validate the RFCs.

[mandar1jn]

A command would also mean that not only do we need a test procedure, we also need to abandon our merge first fix later approach

[wassfila]

true, that is even related, if we cannot properly test or do not have a clear test deployment, we tend to merge it and test it on prod deployment.

[MarcusOtter]

Crossposting that Discord-native polls is being worked on