I think there two ways to address the question of “voting process”
- Procedure to decide a custom voting procedure for each vote (before it begins, as part of the discussion process), or
- decide on a voting approach for all upcoming votes
I think in this early stage, it will be a combination of the two. I see that some people did not like the BRI voting process, so let’s see if we can come up with a better one. I already see a discussion on this. I believe the best way forward could be a two/three step voting procedure, where users are able to vote on a wide variety of things, including “yes”/“no”, and multiple options, at the same time and with only just a few steps.
Most importantly - voting MUST NOT be complex and shouldn’t take much longer than what was needed for the BRI. Two/three screens at most.
That sounds weird to be and I can’t really understand how it can be done without a lot of complexity. We have used a few PR teams already and so far have not really seen them to be as effective as their budgets will suggest. What I can see is some kind of a bounty for getting good PR/marketing opportunities for aeternity. I see James from Telegram wants to get ae in CoinDesk. I am not sure about the details, but if this is something different from: 1. Check how much it costs. 2. Pay. we will be happy to discuss it.
Staking means implementing PoS mechanism. I am not sure if this can be used only for voting or must also be used in consensus building for blocks. If it is the latter, moving from PoW to PoS will be a heated discussion. So far PoS variation are considered “work in progress” various people considering them superior or inferior to PoW. BFT PoS looks most promising, but such a fundamental change to the protocol will take a long time to implement (even if there was consensus that it must be done).
I know that delegation will soon be possible for aeternity governance as it is. This means that users will be able to delegate their token weight (no transfers of tokens) to any other users who is able to vote for them. I think this will take ae governance a step further, although the approach introduces a number of issues too.
I would suggest for the community to first decide on what they want to vote on, then how. A sample voting app for the new vote (based on the open-source BRI code for example) could be a great way to “exemplify” the vote and will be a great point of reference for any discussion.
This is how I see it:
- Determine what will be voted on.
- Propose a draft voting process and implement it in an aepp.
- Share the aepp around and get feedback.
- Incorporate feedback
- Share the aepp again.
- Announce a voting period
- Propose protocol change
Step 9 should happen at least two weeks before September 2 if the result of the vote is to be implemented with the next hard fork.