RFC 7: Update voting thresholds

[Akarys42]

Our current voting system has various flaws that I detailed in a staff chat, copied below

Using our current count of eligible voters of 14, if a pool is 10 👍 0 👎 3 🤷, and the last voter is against, they would rather put a 🤷 to reach the abstaining threshold than a 👎 which would have a very tiny effect. Arguably that's an extreme case, but with one more voter, it is the same for 8 👍 3 👎 3 🤷.

It is also worth noting that 9 👍 5 👎 0 🤷 is considered a pass, which already seems quite controversial, while 9 👍 1 👎 4 🤷 is considered a fail.

One last, perhaps less note-worthy flaw is we don't account for people simply not voting. This means that 4 👍 0 👎 0 🤷 is considered a pass, while it is clearly not enough people gave their thoughts.

This suggestion uses numerical thresholds that aim to simplify the voting process, along with making it more resilient against strategic voting and removing some unexpected results.

It also removes the need for admins as tiebreakers.

Rendered view

[Kroppeb]

This means that 4 👍 0 👎 0 🤷 is considered a pass If there are 14 eligible voters wouldn't that mean that there are 10 people abstaining, and therefore wouldn't pass?

To be fair, I kinda find it weird that there are 2 options you can choose if you want to fail the vote, (abstaining/neutral and negative). I would think you'd just ignore any abstaining member, and count the rest. The reason for voting 🤷 should be so that others know you don't intent to cast a vote and should be reminded/pinged for this vote.

Requiring a 75% positive vote count also feels a bit excessive.

Note that in your proposal it's still possible that for a member they can switch the result from "passed" to "failed" by removing their negative vote.

[mrmangohands]

I propose simplifying to "1/2 of eligible votes need to be in favor to pass, and if 1/5 are negative it fails anyways". This has the benefit of the goalposts for a vote passing not moving during the vote, which seems like an unnecessary source of confusion/uncertainty (and is in fact what caused us to unwittingly adopt such a bad system in the first place). I'm also not convinced we really want to be treating abstentions differently from not voting - I worry they encourage people not to act on reservations they might have and think we should just limit the system to yes and no. Short circuit margin would be 80% positive, and we want a delay before that triggers so staff have a chance to look over the application and provide any info or perspectives that might still materially affect the vote. We've tentatively agreed 3 days for that on Discord.

[mrmangohands]

I've pushed a commit with the changes I've proposed https://github.com/mrmangohands/rfcs/commit/4c94aada0f5fc3e9c17da9cae19c4cd505d12ec7

[Akarys42]

I've updated the thresholds to match the one discussed internally. The number of conditions has been reduced to two, with only one being a non-linear formula, to avoid unexpected behaviors (ie. 16/5 passing but 24/6 failing, as seen in @mrmangohands' proposal). Explicit abstentions have been removed from the formula and only used for closing the poll early.

You can find a visual representation of those new conditions in that spreadsheet.

Considering the community team agreed to this change as per this internal poll, I am going to start a one-week-long FCP on this change.