Goal

I hope to discuss the current situation around polls and to clearly list a few potential improvements that people can seek to build. There are process improvements, which I hope to build with the help of others, UI improvements, which could have bounties built for them, or could have community members build for donations or requested foundation reimbursements, and protocol improvements which I expect won't be built any time soon.

If you want to help me put together proposals for poll requirements and poll validation definitions, please reach out on slack or discord.

Making a Poll

A poll can be made by anyone with over 100,000 GRC in a wallet. It requires a question, a discussion thread, and choices for the voter to make. There has not been much time and research spent on analyzing poll data, nor has there been recent and clear discussions around poll requirements. Nonetheless, there are a few expectations when it comes to making a poll. If these expectations are not met, it is easier for the community to claim a poll as invalid. It is my hope that we can build on these expectations and work to turn them into clearly defined and advertised poll requirements and parameters. This will greatly reduce the human involvement required to validate a poll.

Expectations

Note: These are not my personal expectations. They are what I have gathered from the many disparate conversations around polls that I have witnessed.

A poll is expected to have an abstain option. Source A poll is expected to have its own discussion thread. A poll is expected to use unbiased language. A poll is expected to present unbiased, varied, and clearly defined options. A major poll is expected to last 4-8 weeks.

@GUK is leading the development of a whitelist/greylist process and clear definitions for these polls are being made. The conversations can be found here (Listing v1), here (Listing v2 -- WIP), and here (De-listing -- WIP).

Types of Polls

I can think of five different types of polls:

Opinion Looks for general thoughts from the community.



Development Involves protocol development. Requires action if validated and passed.



Proposal Involves all non-protocol development, such as marketing and management. A proposal is presented and vote on. A proposal may or may not contain a funding clause. If validated and passed, the entire proposal is acted on.



Funding Involves requesting funds from the foundation.



Whitelist -- see above.

Poll Validation

There are currently no clearly defined poll validation definitions. There have been attempts, however the outcomes of these polls can be argued due to low participation and enforcement precedent. For example, the foundation vote-weight validation requirement poll did not meet its own definitions and the the first reimbursement poll had 15% vote-weight participation, yet was still considered valid.

Additionally, using total vote-weight as a validator comes with a few separate problems including:

The requirement of a whale to vote to validate a poll, while whales might not want to control a vote -- which happens when a whale votes.

A good amount of magnitude is tied up in the pool and cannot vote.

It is impossible to reach 100% total-vote weight participation due to burned and lost coins. This problem might be amplified if and when we work burning coins into the economy on larger scales.

Until we clearly define and advertise validation definitions, I think it is a good idea to include a validation clause in any proposal.

Potential Improvements

These are ideas I have seen discussed in one place or another. I do not take credit for them.

Process Improvements -- Immediate

The following are process ideas and do not require protocol changes or coding of any sort.

Find a new way to validate polls other than "total vote-weight" percentages.

Build a clearly defined set of requirements that make a listed poll valid.

Build a clearly defined set of poll validation requirements for each of the five types of polls (whitelist is already in development).

Ensure that these polls meet their internal requirements and pass with overwhelming support. This eliminates the need for "meta" polls. The idea is that the more support the proposed requirements have, the harder it is to argue with their implementation and enforcement.

UI Improvements -- Short Term

Implement the ability for users to view polls based on popularity via vote-weight and number of participants.

Implement the ability for users to hide/differentiate polls they have already voted in.

Ask the poll maker to assign a "poll type" from a drop-down menu. Implement the ability to sort polls by "type".



Notify a user of a new poll and polls nearly ended, along with their types through a "Polls" section (or something similar) clearly marked on the wallet "Overview" page. Allow users to vote directly from the "Overview" page.



Differentiate polls that a user has not yet voted in.

Protocol Improvements -- Long Term

Build the processes into the protocol.

Build an in-wallet "forum" for each poll where posts are saved on the blockchain.

Build alternative vote-weight definitions, such as logarithmic vote-weight.

Have more ideas? or thoughts on one of the suggested improvements? Leave them in the comments!

If you want to help build a proposal around poll requirements and processes, reach out on discord.