In discussion of the early voting penalty change in HF20, an attitude I'm seeing over and over is: our first priority is stopping people from exploiting this bug. This post is my attempt to explain why that's a terrible plan.
When we're designing a system, it's important to have our priorities straight and constantly in mind. This is why some of us have mission statements, to make sure that we don't narrow down so far onto a perceived problem that we stop taking the whole system into account, and make decisions with ill-considered side effects. In particular we have to know what actions are most important to the success of our system as a whole in order to make good decisions about each individual piece.
In any growing system, there's a strict hierarchy for what's important on a basic level:
- Encourage and reward new users.
- Encourage and reward desirable behaviors.
- Discourage and punish undesirable behaviors.
(In a system focused on retention #1 and #2 can flip, but #3 only ever moves up if you're actively averse to new users.)
If you treat those three priorities as if they were progress bars, anything that moves a progress bar up but moves the ones above it down is a bad idea and you should come up with something better. Of course, if you treat those priorities as progress bars, the first one on Steem is so far in the negative that you'd need a second monitor to see it all. The reason for this is Steem's design priorities look like this:
- Discourage and punish undesirable behaviors.
- That's it.
We can see this in the way 
Users reported two exploits: (issue 2428 and issue 2539), where an account could gain extra voting power by using up all of their voting power, and then delegating their SP to another account, or powering down and powering up again into another account.
We are including fixes for these exploits as part of Hardfork 20.
(These are also highly technical, so feel free to skip over if you’re not interested.)
Not only do you basically have to be a complete nerd about these changes to have any idea how great it is, they specifically tell you you don't have to think about that part. They reinforce this at the end of the section:
This will not negatively impact the user experience: it is a technical change designed to specifically address the double voting exploit.
They've made a clear and strict improvement to the system for everybody, and their pitch for it is this will not negatively impact the user experience. They ought to be saying This is pure awesomesauce, what a marvel of system design, let us celebrate it! I am not a fan of self-congratulation but Voting Mana deserves it. Instead they downplay the whole thing and tell you you shouldn't care, because this is all about stopping the exploits.
Voting Mana should be the shining example of how to redesign how the system works, the standard to which we hold all other proposals.
We need a change in attitude.
Priorities on Steem need to be re-focused on making the system attractive to new users and continually compelling to existing users. The early voting penalty change in HF20 is just one terrible example of what happens when we don't do that. It's so bad we can't even document how the voting system will work after the change in a way that is coherent and appealing to new users. That's why Steemit has been so bad at communicating it that I've had to explain how it's really going to work to several witnesses now. Approaching it from a historical perspective doesn't work so well either:
The last sentence in that paragraph might as well be "Buy EOS." This isn't how an appealing system is built. We can do better, and we should.
It starts by always, always, always thinking about the experience of new users first. Because growth is the key to a viable Steem in the future.