ALP01: Carbon Feedback for Github Issues

[lkngtn]

Proposal: Carbon Feedback for Github Issues

Author(s): Luke Duncan, Aragon et. al.

Last updated: 11/29/2017

Abstract

Many community governed projects are open source and use Github for project planning and discussion. However, it can be difficult to judge community consensus related to open issues. This proposal suggests using a Carbon Vote inspired mechanism to give a communities token holders the ability to signal their support of an issue.

Proposal

At a minimum a successful implementation of this proposal would enable the following user stories:

• As a repo admin, I'd like to be able to enable token-weighted signaling in support of issues
• As a repo admin, I'd like to be able to configure multiple voting options for an individual issue (e.g. approve option X, approve option Y, disapprove)
• As a token holder, I do not want to lock my tokens
• As a token holder, I want to keep my tokens on a hardware wallet
• As a token holder, I want to be able to signal for multiple issues simultaneously

Rationale

Pros

• This is a safe and inexpensive mechanism for getting community feedback, and provides immediate utility for token holders. There are no tabulation costs for votes, and security risks are minimized because tokens never leave the users wallets.

Cons

• Lack of on-chain tabulation means that this cannot be used to give fully decentralized authority to token holders.

References

Aragon Signaling App - An initial version of this proposal has already be developed by Aragon for use by ANT holders to participate in governance decisions. It may need some UX improvements to be ready for general use by other organizations.

[lkngtn]

While this issue describes a basic direct voting approach to signaling, it is possible to introduce more complexity through delegation as well. Adding delegation solves many issues related to rational ignorance, and cost of participation.

Opting to experiment with more advanced voting mechanisms using the carbon vote approach first reduces the need for off-chain scaling solutions for tabulation.

[luisivan]

This makes a lot of sense, and we should get a basic but working implementation of the signaling app ready soon. When the UI for 0.5 is finished, we could just deploy a DAO to the mainnet and use the default Voting app with some sort of linking to GitHub Issues -- which in the beginning could be very manual, just having the core team curating the Issues that will become a target for a vote.