OpenGov Modification - New Status

OpenGov Modification - New Status

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 :wink: 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.

Isn’t this then already supported by commenting on the proposal on polkassembly etc?

@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.

1 Like

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