Guardian community voting for Guardian Roadmap Features

[anvabr]

Problem description

Currently there is no 'programmatic' way for community to get involved into Guardian roadmapping and design process. Also there is no indication of how valuable and considerate someone's input is, and logically it would seem that if a person/entity is personally incentivised (through financial investment) to work towards the prosperity of the ecosystem their input would be more important and though through than someone's passing comment.

Requirements

• Develop an on-chain voting system which assigns weights to votes corresponding to the hbar balance on the voting accounts.
• The voting system accepts proposals from the account that manages the contract.
• Develop is a simple UI which allows individuals with Hedera wallets with an hbar balance to vote on proposals - similar to https://snapshot.org.
• Deploy the UI and the smart contracts in production.

Definition of done

There is a on-chain smart contract, deployed on mainnet, which operates as a vote counting machine as per requirements above.

Acceptance criteria

The voting system is hosted and votes on proposals can be held as per requirements section above.

[dubgeis]

I think the weight should also be considering the importance of the commits, and how contributors gain voting weight from their commits, as well as institutional needs (asset creators/consumers). In my mind the snapshot should include:

• Org vote (group of accounts/dev contributions)
• Org development
• HBAR Balance (Individual and/or org)
• Asset Production/Consumption as starting points.

All of this is of course a starting point and needs wide input in this discussion. cc: @sergmetelin @justin-atwell

[anvabr]

• Org vote (group of accounts/dev contributions)
• Org development
• HBAR Balance (Individual and/or org)
• Asset Production/Consumption as starting points.

@dubgeis to clarify, if the votes are to be verifiably counted on-chain, from the list of parameters above the counting smart contract would natively have access only to the hbar balance of the account doing the voting. The rest of the information could probably be packaged into an Oracle, and thus made accessible to the smart contract logic. It would require non-trivial amount of work.