The Problem
During the last developer meeting, we ran into a problem. There were 10 “hot topics”. This is a good problem to have because it means that there is a ton of interesting conversation ahead. It’s a problem because the meeting is only 90 minutes long, not all the topics were discussed and we could not get to the team updates.
What to do? We have a limited amount of time and too many hot topics to cover in that time. How do we decide the order of topics to be discussed during the limited amount of time?
In other organizations, this might be decided by the meeting organizer or it might be a first come/first serve basis. Relying on one central point to make the decision on the order of hot topics is a pretty central way of doing things. First come first serve sounds fair on the surface of things until we consider that Status is a global organization and we all work in different time zones.
The Voting Dapp
The voting dapp can help us decide on the order of what will be discussed in a way which is decentralized and fair by allowing meeting participants to vote on what they would like to discuss. The topic with the most amount of votes will be the first topic to be discussed. The topic with the second most amount of votes will be the second topic to be discussed. This will continue until the hot topics time allocation has run out.
To add an interesting element to the mix the voting will be quadratic. A user has a set amount of votes which are derived from their token holdings. Votes become more expensive when applied to a single choice. This means that if I have 100 votes, the first vote on option A will cost me 1 vote. If I add a second vote to option A, it will cost me the square root of 2, which will be 1.4 votes. This is done to encourage a spread of voting and measure the intensity of choice.
Practically how do we do this? Prior to Monday’s dev meeting, we will get as many hot topics as possible. These hot topics will be collected from Status core contributors as is normally done by reaching via the core dev meeting slack channel.
The topics will be added to a multiple choice poll with the title, “what hot topics do you want to discuss?”. Below there will be all the hot topics collected with the option to assign votes to each topic. After the votes have been assigned to the topics a user can write their votes to the ethereum blockchain by sending an empty transaction to the voting dapp. This will cost GAS at around 0.2 to 0.6 USD.
Who gets to vote?
This in itself is a tough governance issue. For this iteration, we have a created an ERC20 token called “status core developer” token. This token will be distributed in equal amounts to the Status wallets of all the people who are in slack channel #Core-Dev-Meetings. In the interest of inclusiveness, the link for the spreadsheet is here, add your name and status wallet if you would like to vote: https://docs.google.com/spreadsheets/d/1kNBDB0EwstptOwUpnZW3Hn0lq85_z2hOd17yHl2ZiWg/edit?usp=sharing
Is this the best way? No, it’s not. There must be better ways to securely allocate voting rights based on participation and expertise of meeting attendees. But for now its the simplest and a great challenge to solve for the next iteration.
Why?
At this point, you are probably saying, “Wow that seems like a real hassle and I have to pay GAS! Why don’t we just use a polly poll or google form?”
We could use a polly poll or google form and it would be super easy to create and vote on. The reason for using the voting dapp is not because it is easy but because it provides us learnings which take us a step closer to having more and more decisions been made and executed using decentralized governance processes which are fair, inclusive and ultimately allow us to make better decisions through collective wisdom.
Through this experiment, we hope to learn if quadratic voting leads to a fairer distribution of votes and by making sure meeting members have tokens in their status wallet before the vote lowers friction to participate.
Love to hear your feedback, questions, comments advice for next iterations. If you believe your team or swarm could benefit from this governance process please contact me and we will set something up.
A big thanks to the hard work which has gone into this project from Richard, Euge, Patrick, Ricardo and Barry.