After being involved in governance on Polkadot from the early council days, I have seen one (hopefully minor) change that could be made to improve the experience for individuals raising treasury proposals and for voters, especially the ones with larger amounts of DOT. I have seen the importance of this develop as DV has rolled out where individuals and groups in the community are tasked to vote with higher amounts of DOT.
Currently, I believe that the existing statuses (AYE, NAY, ABSTAIN) we have with voting are great for an âend resultâ however donât always give the right signal to the proposer and community during the voting window. One pattern Iâve seen is individualsâ NAY or ABSTAIN proposals until they find time to research further, or while they wait for discussion or problems to develop. I believe this signalling can be problematic, especially for NAY votes, as from the outside point of view it appears that an individual has decided to vote against a proposal.
The proposed change is to add a new status to, DELIBERATING / DECIDING. From a signaling point of view, it can be used to show that voters have âseenâ a proposal and are working out which way to vote. From a support point of view, it can be classed the same as ABSTAIN, so it adds to the total support for a proposal, however (obviously) doesnât add to the approval curve in any way.
Iâd like to open the discussion here on the forum to gather community thoughts / feedback before potentially proposing an RFC. I know there are MANY modifications we can make to OpenGov, so letâs not go blue sky thinking with ideas Thoughts on the above?
We donât really need runtime changes to implement this. Just need governance UI to collect such reason and display it somewhere. And if indeed this is a commonly used feature, then we could consider integrating it into runtime or not if the frontend change is good enough.
Well, we would need a runtime change if we want it to count for support. But Iâm not sure it should be considered as support. All of {Aye, Nay, Abstain} are âfinalâ votes - yes, you can change them, but they mean âI have made a decision on thisâ, and any non-Nay vote counts for support. But âDecidingâ would potentially be a âNayâ so it doesnât make sense to me to add it to Support. But Iâm open to opposing arguments here.
And if you donât want it to count for support, as Bryan said, it could easily be added to a front-end UI - if you want it to be on-chain, you could even make a format for system.remarks (âDECIDING REFERENDUM 999â or whatever) that Polkassembly/Subsquare can read, without any runtime changes.
So tl;dr - I think it makes sense to have this feature, but it should probably just be on the front-end and not included in support calculations.
@bill_w3f I do agree with you - maybe this shouldnât be counted in the support.
The issue with doing it in a UI only is that the UIs donât tend to agree on certain things, it also makes it unclear for new providers etc.
I agree a system remark could improve it, but having it properly onchain makes more sense IMO.
I do like a âdeliberatingâ vote, but what are the on-chain semantics?
Iâd think a âdeliberatingâ vote means youâre asking for more time, in the sense that it delays the closing in opengov. It follows âdeliberatingâ would still be some form of ânayâ vote, but behave slightly differently on-chain.
It might expire for example, so maybe a ânayâ that counts as an âabstainâ after some delay?
One more point, usually when I nay, what I really want to say is ârequested fund too much, cut it by x% and I will ayeâ.
Right now it is always the proposer to come up a number, if it is too low, it is the lost of the proposer. If it is too high, the proposal may be rejected. But we donât have a good way to reach a consensus with the community on a number. We can do offchain pulling but no one votes it and it is not enforceable. The old tipping mechanism is a (not very effective) solution and I think we need something better.
It would be nice to have a vote-weighted payout amount, where the high end is enforced by the track itâs on (or there is a special track for it). Ideally the proposer can commit/reveal a minimum amount that they are willing to accept for the work, and after it passes then the proposer reveals the minimum to claim the payout (and if the offered amount is below the minimum, it fails).
Longer-term though Iâd like to see the Tech Fellowship (and now Ambassador Program) and future collectives be more active with their treasuries. Itâs difficult for âall DOT holdersâ to put out RFPs, but it seems manageable for a collective to say, âwe want X to be done and will pay Y {DOT, USDT} for itâ, and then people can apply to do it.
Agree 100%. In general, I think it makes sense to have more âspecializationsâ. Keeping up with governance is a full-time job right now, and delegations are useful but not perfect. It would be more sustainable (and also more scam-resistant) if more Treasury spending was done via Bounties with specialized curators, or Collectives did more
Thoughts on the above?