We’re looking to enable Devcon ticket holders to be able to vote on elements for Devcon 6 using TCR-like permissions and quadratic voting.
For Devcon 6 we are looking to enable an (optionally) on-chain, quadratic voting implementation where attendees can vote to determine a small subset of Devcon speakers (E.g., 1 speaker chosen by the community for each of the ~7 tracks, or something of this small magnitude).
Through this integration, we aim to achieve several goals:
Community involvement. Devcon is a conference for the community and as much as we can make it run by the community, the better!
Transparency. Though all speaking applications are reviewed by panels of community members who are experts in their area, we understand that there are benefits from increased transparency of speaker selection and this community voting integration could aid with that.
Dogfooding. This year we will be able to represent Devcon tickets on-chain using AlphaWallet’s on-chain attestation libraries, and as such will be able to have curated on-chain registries of Devcon ticket holders! Allowing them to vote via that on-chain curated registry would be cool. Also, using a quadratic voting mechanism, we can allow attendees to indicate the degree of their preferences rather than just absolute preferences.
Low risk. This is an experiment, and as such we need it to have a low impact and low risk. This vote will result in at most the selection of under 15 speakers, and perhaps may not be used for speaker voting at all. If this experiment goes well, perhaps it can be expanded in the future. Notably, the full benefit from an integration like this will not be manifested this year, rather this may pave the way for expansion of this idea in future years and, in turn, greater impact.
We have two options:
- Build our own custom quadratic voting application into devcon.org for this purpose
- Utilise an existing quadratic voting application, perhaps with minor modifications, and integrate it into Devcon.org
(what we wish for, specs, …)
- The platform must have a good, simple UX
- The platform should be able to accommodate quadratic voting mechanisms
- The platform must be able to be extended to integrate with AlphaWallet’s attestation libraries to ensure only those that have a Devcon ticket can vote.
- Review the AlphaWallet DIP for more info.
- Platform should be ready by February 2021
- The platform must accommodate our tentative voting parameters:
- The community will be able to select one speaker for each of the 7 tracks.
- There will be a list of ~5 speakers to vote for in each track, one will be selected
- The voting period will last for 1-2 weeks.
- We would prefer to use quadratic voting (the exact # of votes given to users can be discussed: 5, 10, 100, etc) to allow attendees to indicate degree of preference rather than be constrained to indicating only absolute preference.
- Should votes be cast on-chain or off-chain? We lean for off-chain for a better UX and a lower barrier to vote/no gas costs, but are open to other thoughts!
- Are there other considerations we should be taking into account with these voting mechanisms?
- Maybe there is another better-suited mechanism than quadratic voting?
- What kind of privacy preserving or anti-collusion mechanisms could potentially be integrated?
Comment below for questions, clarifications, or simple ideas. If you have a proposed solution, start a new topic that details it specifically, and welcome comments, feedback, and discussion! The idea should address all points made here, as well as all requirements laid out in DIP-0 . After evaluation of your idea, we may ask for a more in-depth demo.