This repository has been archived by the owner. It is now read-only.

ALP02: Token-weighted Github Issue Prioritization #2

Open
lkngtn opened this Issue Nov 30, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@lkngtn
Member

lkngtn commented Nov 30, 2017

Proposal: Token-weighted Github Issue Prioritization

Author(s): Luke Duncan

Last updated: 11/29/2017

Abstract

A significant factor in governance is the visibility and discussion of issues prior to any formal decisions are made. In token based communities, tying the curation of issues to a token weighted mechanism enables projects to highlight the issues that the community collectively feels are most important. This can be a catalyst for community engagement and discussion.

Proposal

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

  • As an admin, I’d like to be able to have new issues automatically appear in the dApp without manual intervention.
  • As an admin, I’d like to be able to manage which issues appear in the dApp based on “labels”.
  • 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

  • Users can only use their tokens to signal for one one issue at at time, therefore they must make an economic choice in which issues they signal for. The result is a prioritized list based on token holder feedback.
  • Signaling is stake-weighted, so we can assume that the priority should to some degree align with the interests of token holders.
  • Token-holder and Developer attention can be focused on the discussion and implementation of issues which the community has deemed most valuable.

Cons

  • Token-holders are not necessarily the same group as the networks users, and in particular “whales” have a huge influence in this process.

References

A similar approach has been taken by district0x with their district proposal process. Their implementation has been live for quite some time now, and it appears it has been a large part of their community engagement. The code is also available in the District Voting repo.

Open Issues

There is a lot of overlap with ALP01, in that both can use a carbon vote inspired signaling mechanism. It may make sense for these issues to be combined into a single interface.

@stellarmagnet

This comment has been minimized.

Contributor

stellarmagnet commented Jan 11, 2018

Users can only use their tokens to signal for one one issue at at time, therefore they must make an economic choice in which issues they signal for. The result is a prioritized list based on token holder feedback.

I like this proposal, but how about also enabling "dot voting", so you can stake-weight a user-specified % of your total token supply against different issues?

For example say I have 99 tokens, and there are 10 issues, but I am very concerned with 3 issues on the list, and to me, they are equal priority. So then I can stake-weight 33 of my tokens to each issue.

@lkngtn

This comment has been minimized.

Member

lkngtn commented Jan 11, 2018

Definitely could see this being expanded to include other mechanisms! in fact what is described here is arguably not a very good process from a social choice perspective compared to more elaborate schemes (Dot voting, Range Voting, Approval Voting), the main benefit is that its simple and gives token holders more voice than they otherwise would have.

The challenge with this proposal is that it is a non-binary choice, which based on Arrow's Theorem means that no matter how we choose to vote we are making some sort of compromise. Thus, each methodology has strengths and weaknesses so it would be good to eventually support all of them. :)

Perhaps making a new ALP for dot voting makes sense and then it can be linked to this one?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.