WIP Voting for Leads, Referendum + Appeal Proposals

[traumschule]

A possibly long-standing unsolvable issue, likely post-post-mainnet.

The current Election System (#896) is great but has some shortcomings:

• Reuse staked coins for voting #143 was not implemented
• Factor out voter decision making from council election #139 was not implemented and can probably not be solved by Delegation in voting #140

Looking at mainnet issues the following changes to the proposal (#1200) and council pallets may be expensive but could help to remedy these and improve the quality of processes within the DAO. Where possible outstanding changes (#1984) could integrate selected ideas. If parts turn out valid they should be addressed in separate issues.

Leads vote on proposals

Rationale

Their inputs are essential for consuls to make informed decisions. Leads are automatically paid and staked to work for the platform. Ignoring their opinion would be a waste of resources.

Scope

Leads have automatic voting power on proposals.

Leads stake councilors

Rationale

Same reason as above.

Scope

Leads can stake candidates during council elections equivalent to the total WG stake. This would incentivize to hire workera by stake to strengthen committment to the DAO.

This would allow for proper representation of working group members (#143).

Referendum aka Stake-Based Voting

Rationale

Council elections implement referenda but the proposal system does not.. This change would enable all token holders to influence proposal outcomes based on their funds.

Consuls can use this to start a public vote on specific topics to feel the temperature or offer binary choices.
Council is advised to carry out daily tasks based on those binding votes that reflect the option of the whole electorate (share holders).

Scope

The proposal creator may switch Allow stake based voting (versus one consul one vote).

This could either be a separate proposal type or be an option for selected existing proposal types (like signal, - especially interesting in combination with #2177 or its emulation, fire lead

• see Collaborators for all roles #2870, and possibly others).

Spin-Offs

A fictional createRuntimeDAO Proposal (#2068) could make use of this functionality to spin-off an organization funded by the total voter stake. Needs more thinking:

• stakes are locked for the lifetime of the Runtime DAO and fill its initial mint
• Runtime DAO ends either (1) by another fictional liquidateRuntimeDAO proposal after achieving its goals or voiding its initial purpose (eg. disposing a legal defense fund after settling a claim) which would return the current mint. (2) garbage collection removes Runtime DAOs with empty mints after a serious amount of time (for the opposite case where initial founders went insolvent).

Appeal Proposal Type

Rationale

A referendum to give the community a say about the productivity of one or more consuls or the whole council to temporarily lock their reward relationship (#148) until the issue is solved.

Effects can be to lock voter stakes, #2760 and/or to invoke an external party (for example aragon court). The author assumes better outcomes than for example bans (#2375) because by locking stakes over time or repeating appeals.a consul would find it harder to find backers. Locked tokens could be burned over time to fund conflict resolution which motivates involved parties for speedy resolution.

Scope

Add Proposal Type Appeal or Complaint as way to either (switch on creation)

• revoke an executed Proposal
• claim that a proposal was not properly implemented by the council

This would be different from a Veto (#1982) which stops a recently approved proposal from being executed. This is also not to signal that proposal execution failed due to a technical issue (#2740 or #2480) but (in)action of (parts of) the council with the intention of (temporarily) withholding their rewards.

The stake for this kind of proposal should probably be significant.

┆Issue is synchronized with this Asana task by Unito

[bedeho]

Love the effort and sprit of this suggestion, and really blown away by the level of detailed understanding 🤯 .

Be aware that this issue is resovled in Olympia: #143

For pretty much everything else, this would be super expensive to fix as there are cascading changes from the runtime, to query node, to cli + pioneer, so really all of this has to be part of the post-mainnet agenda to be triaged, so added that label.

If you are interested in contributing on the runtime side to stuff that will go into mainnet, check out these issues

https://github.com/Joystream/joystream/issues?q=is%3Aopen+is%3Aissue+label%3Amainnet+label%3Aruntime

There are also a subset of issues good-first-issue that can be easier to try.