Do not show results until the motion is closed

[mitar]

As an option for motions. Moderator should choose what they want when opening the motion.

[mkanwal]

Having people openly see results may sway members towards a consensus where they will agree with the popular option if it results in passing quorum quicker. This can be both good and bad: If a member was misinformed about a motion, then they will self-correct potentially (caveat: "Wisdom of the Crowd"), but on the other hand, psychologically, people may want to feel like their side won, so they will compromise their original vote. If a voter believes strongly enough in their choice, they will most likely ignore others' votes.

[mkanwal]

Open results also lead to more competitive elections: When results are close, candidates campaign harder. This can be both good and bad. Good because it leads to candidates reaching out to members and getting to know them. It also really invests candidates into the position. Bad because things can become cutthroat and candidates can talk negatively about others, which is generally bad for the community. We probably don't want a major manager elected because they were able to talk a lot of shit about other candidates.

[mitar]

One reason why real-time results are important to be shown is to counteract potential strategizing against statistical quorum. If users see that something is going to pass because a group of users got together and quickly votes as a block to pass something, they can see that happening in time and start voting against it.

There is also a middle ground here which would be that results are hidden until the confidence reaches a threshold (it could be lower threshold than a passing threshold) and only then it is open. So users have time to vote, and if it is a contentious issue it is now shown how closely the results are (but one could probably guess/compute from the confidence - if even confidence would be shown), but once it becomes more stabilized (or is ready to be passed), others can see that it is to be passed and can start voting against it at that time, if they disagree and were not part of a strategizing block.

[mkanwal]

To best implement the above middle ground approach (which seems like the right way to go), we need to do a few analyses:

• Under various assumptions on the rate of adversarial attack (correlated voter surges from special interest groups), at what "public display" threshold can the majority opposition counter the attack and prevent the "pass" threshold from being reached?
• At what rate does the majority opposition need to vote at to beat out the special interest group in the above scenario for some fixed "public display" threshold in our current version of statistical quorum?
• What validation mechanisms can be added to the decision-making pipeline to counter adversarial attacks beyond the intrinsic theoretical robustness of statistical quorum? See #58 and below.

[mitar]

So my current plan is that when moderator is opening the motion they can select various options (majority/super-majority, veto/no veto, -1-1/0-1/yes-no range, display results from the beginning/when quorum is reached/after voting is closed). And then after some time and many users we can start analyzing how things work together.

This is related to the idea that we remove the message of succeeded/failed motion we display automatically and allow moderator to decide how they want to read things we compute (and then they select winning motion when closing). So that we just give users various signals and users decide how to understand those signals.

Those ideas to analyze are good though and we should do them and maybe then inform moderators that some combination is maybe opening them to an attack (and which type) and so on. Or ideally, we detect that such attack is happening and warn them. Or something.

[mkanwal]

(addendum to my previous comment)

The major assumption people might not like about a statistical quorum is that we assume "yes" and "no" votes arrive independently according to their likelihoods. In reality, we may get a ton of correlated "yes" votes at once leading to quorum, later followed by a ton of "no" votes as a counter. The dynamic statistical quorum (time-dependence) helps mitigate this flaw. (Also, I now realize this will have been majorly mitigated in the new vanilla statistical quorum that includes a normalization factor in the Beta prior scale parameters.)

But what if we want to keep votes private until the population reaches (or is close to reaching) quorum? Then there might not be an opportunity to counter fast enough...

A "post-quorum (or near-quorum) validation phase": With a dynamic statistical quorum, there is a very natural way to incorporate a validation phase (rather than saying quorum has to be maintained for 1 week after passing). All we have to do is reset the upper bound on the effective population size to the true population size, and reset the incoming votes rate. Then everything takes care of itself: The population just has to reach quorum again. If lots of votes come in after results are made public, then the expected number of remaining voters will remain high, so quorum will take longer to reach. If no new votes come in, then the credibility will quickly converge to the pre-validation credibility.