TLDR: The code may be fine but the voting rulebook is demonstrably flawed.
At 12:30, the speaker (disregardfiat?) shows the variable voting is apparently done by [stake-weighted] averaging (a voter with 1% stake changes 200k to 1M and the result moves up 8k) and explains "no big fluctuations" as the advantage of this system, apparently compared to (stake-weighted) median. (a system that I understand to be used on Hive to decide consensus witnesses' vote for HBD Savings APR).
While that may be true, the method only (somewhat) works as long as the voters stay naive (=ignorant of the rules and their practical consequences) and enter their preferred value as their vote.
Let's say all other voters want instant powerdown so 99% of the stake is voting for 0 on that variable. End result: 10k (blocks). In my book, that's a failure (I want the ruleset to declare the result as 0).
Am I allowed to "correct" and vote a negative number? (minus 1M if I have 1% stake in this particular case)
In practice someone has to set an upper and lower bound to valid votes. Often an arbitrary one. Although at times there are natural boundaries that work out poor - such as the zero lower bound here - those may favour one side (the long powerdown camp in this example).
Do we vote on the bounds first? Do we settle the vote with averages?
Wait, why is that? Well, most voters should vote for the minimum/maximum allowed unless they either (1) possess a large stake or (2) are lucky to have the current result close enough their optimal value. If you are this rare voter, you can calculate a value to get your dream result but you need to follow any changes and recalculate when a vote is changed. Total mess.
There is a correct way. Keep using median. The way to deal with rapid changes is to look at the current value in addition to the vote result and mildly push the new value in the direction of the result of the vote. Think of an ELO rating changing after a game - towards the 1-game performance rating but no overreactions.
You're mostly right here, but at the end of the day I don't think it matters. Staking didn't stop the Sun takeover, and median values are exceptionally unlikely to be ideal values. The moving average here is done to give the most number of people the ability to vote, as a system that calculates median values would need to store and calculate all accounts votes at every vote, which won't scale. What seems like a median on Hive really is the median of 20 accounts who have a few key votes, a barely decentralized plutocracy.
The number of people who have left Hive is just shy of all them. Let's not stretch our imagination too much and think 90% of accounts hold 20% of the stake. On Hive there is nothing they could do even together to get a single witness voted from outside the top. At least with this system they could exercise 20% of the vote toward governance. The top 20 in this paradigm are the people who vote for all the apathetic accounts... which would have prevented the Sun takeover. It also disallows the biggest accounts from exercising more than 5%(hopefully closer to 2.5% with 50% apathy) votes as well, which addresses the last point: Any single vote won't effect a variable more than 5% in the arbitrary range.
The code does have vote range limits, so a negative vote will just be counted as a minimum. At this stage at least most of the range limits are fairly natural. Interest rates can't be negative, key holders are limited by Hive code, power-down voting range is something like 1 to 100 days... (which translates to 4 to 400 days for a full powerdown). The flip side is the 13 week power down on Hive is almost kinda voted on when there is a hardfork... but as much as people want it to drop in line with the rest of the market, there isn't even a path to do so.
To sum
Pros:
Cons: