Suggestions for improving governance as a process

Governance
1

Dear community,

I would like to share a few ideas that I have jotted down and circulated privately related to improving the governance process. Essentially, I would like to see a system in which there is respect for the proposer while ensuring there’s no potential risk to the chain. I would also like to see more meaningful use of the existing phases of governance and more focused voting.

Potential Problems

  1. The discussion phase for proposal review is overlooked. Most discussion arise after on-chain submission.
  2. Some decision deposits are prohibitively high, we should seek ways to allow accessibility without compromising security.
  3. Generally, there is little appreciation for the proposer’s effort and time, the system favours unscrupulous rejection.
  4. There is little incentive for voters to vote early and with true conviction. One may argue that the true decision period is during confirmation.
  5. There’s no means for revoking the submission deposit for Timed Out, Rejected or Cancelled proposals.
  6. At times there are just too many referenda to review at any given time. This can lead to reduced feedback and ‘voter fatigue’.

Suggestions

  1. The preparation time for larger spending tracks could be extended to a mandatory period of 7 days on Kusama and perhaps 14 on Polkadot. This would show on-chain intent and allow for discussion. Considering that votes are allowed during preparation it could also afford early signalling. We could in kind reduce some proportional voting time for the decision phase.
  2. During the preparation phase, the proposer should be able to change spending tracks and/or adjust the spend amount lending on community feedback. With either change, existing votes should be cleared. Track/spend changes can be limited to once every x blocks to prevent abuses.
  3. Generally, decision deposits should be contributory, allowing several participants to contribute towards large sums. To avoid abuses one can implement a minimum contribution amount and a maximum number of contributions.
  4. If a decision deposit is not in place at the end of the preparation period the referendum instantly times out. This should help with quicker time-outs of referenda with mistakes.
  5. The confirmation phase should be refactored to only allow participants of the decision phase to adjust their votes within some constraint.
  6. Those who voted early in the decision phase should have more liberty to adjust their conviction than those who voted later on. This gives an incentive to vote early during the decision phase.
  7. We need to ensure careful calibration of enactment times and readiness of the Referenda Killer track to thwart any potential abuses. We may want larger enactment times for the larger spender tracks.
  8. A permissionless extrinsic should be created to allow for slashing of submission deposits of TimedOut, Rejected or Cancelled referenda. Each of these states are a result of a failure and imo should result in some loss which atm is minute.
  9. Queues should be implemented at least for larger spending tracks. I hope that this would help focus discussions and feedback.

Kind regards,
Will | Paradox

6 Likes
2

Great suggestions - I agree that the discussion phase is currently a nothing-burger, most likely due to the large volume of live proposals that instead take all of the attention. Allowing projects to correct mistakes/ amounts requested/ withdraw/ etc during the preparation phase could help improve approval rates as well as reducing the spam of incorrectly submitted proposals that we see currently.

Some kind of penalty for incorrectly submitted proposals should also help to ensure adequate research before submitting, as currently there is no consequence for not doing your research correctly.

I’m unsure on #5 though, as it’s possible someone has missed the entire discussion & voting period - but should still be able to weigh in on the vote - although it would help with sniping proposals at the last moment.

1 Like
3

I can relate to the problems mentioned and I like the suggestions(don’t quite get #8 though).
Some changes here might be trivial and require only adjustments to existing parameters, others might require mayor changes or even new pallets.

OpenGov definitely needs tweaking and items here are good candidates, the issue is it requires the tedious process of root track referenda and runtime upgrades that we just saw with Adam’s proposal how doing it without the fellowship’s stamp of approval might generate negative reactions and lack of support from community members that trust the opinion of the high ranked members that wouldn’t trust any runtime outside those released by technical fellowship.

So to avoid coming several times to the root track, it might be desirable to first introduce the necessary “infrastructural changes”(e.g. new or mayor refactors to pallets) that enable your suggestions to take place but don’t actually change anything and once implemented then propose the “controversial referendum”. For example, I think it would be useful to have a “dynamic conviction” system that allows calculating voting conviction on the fly based on different whatever logic with decide, said system can be introduced without changing current parameters but later make it easier to add what #6 suggests(or I’d use it to propose reducing conviction when voting with staked funds).

1 Like
4

agreed on al points