UX Bounty - Enhancing Referenda Feedback loop: Introducing Section-Based Voting and Feedback Mechanism

[nino_apillon]

Dear Polkadot Community,

The UX Bounty proposes an enhancement to our current referendum voting system to foster deeper engagement and more nuanced feedback.

Pain Points:

1. Gdocs

Currently, referenda on OpenGov lack a standardized format for proposal documents. Many proposals are shared via Google Docs, which often do not include version history, change tracking and/or archival value after the vote concludes. This issue has already been widely acknowledged by the ecosystem and is being actively discussed:

2. Rigid Feedback System

A key problem is the asymmetry in information flow between proposers and voters. Proposers are encouraged to provide in-depth, transparent documents (which often results in long, detailed proposals) while voter responses are limited to binary choices: “Aye” or “Nay.” These responses rarely include specific feedback on what aspects of the proposal could be improved, leaving proposers in the dark.

Proposers must then wait up to 30 days to learn the outcome. If the referendum fails, the lack of targeted feedback leaves many proposers uncertain about what to change. This discourages proposal iterations or rewrites, causing potentially valuable ideas, often just shy of consensus,to be abandoned.

While OpenGov allows for community comments, most referenda receive significantly more votes than comments, often 50 times more… demonstrating that written feedback is currently the exception, not the norm.

Proposal Overview:

• Introducing Markdown (.md): Standardize the referenda document format and or structure, which also enables technical foundation for targeted voting feedback.
• Section-Based Voting: Allow voters to provide feedback on specific sections or paragraphs within a proposal.
• Interactive Feedback Mechanism: Implement a system where users can express their stance (e.g., , , ) on individual sections.
• Heatmap Visualization: Aggregate feedback to highlight sections with the most engagement or contention.
• Real Time Feedback Loop: Enable notifications for voters upon changes in the proposal, enabling re-evaluation and seeking consensus during first attempt of referenda

Benefits:

• Granular Feedback: Enables proposers to identify and address specific concerns.
• Enhanced Transparency: Provides the community with a clearer understanding of proposal reception.
• Improved Decision-Making: Facilitates more informed voting by highlighting key areas of interest or concern.
• Real-time Feedback: Targeted feedback allows teams to address issues during the first 30d voting window, potentially reaching consensus in the first proposal iteration
• Introduction of Document Version History: Usage of decentralised infrastructure to permanently store proposal documents and their versions creates a binding document resistant to deletion once the proposal has passed

Implementation Considerations:

• User Interface: Develop an intuitive UI that integrates with existing SubSquare and PolkAssembly platforms, allowing seamless interaction.

• Discord Voting Bot: Discuss potential compatibility with the existing Discord voting interface used by most DVs enabling section-level feedback. We’ll need to coordinate with the bot maintainer.

• OpenSquare Voting: Ensure compatibility with the popular OpenSquare voting platform to ensure DAOs, DVs, and other voters can utilize the same tooling.

• Data Storage: Ensure feedback is stored securely and transparently, possibly leveraging decentralized storage solutions.

• Privacy: Maintain voter anonymity while ensuring the integrity of feedback.

Proposed Flow & UI

Positioning of markdown referenda document

As shown on the screenshot, a new “Proposal” sidebar component could display the markdown files for any given referendum, creating a standard and visual cue for voters to see the latest version of the proposal, as well as any previous versions.

Document Version History States

Different states of referenda proposal document, addressing version history.

This modal view shows users a more in-depth view of version history, with clearly displayed age and github inspired content percentage changes, allowing voters to re-examine significant changes and re-evaluate their vote position.

Enhanced Voter Feedback Loop Module

Exploring Ideas for a More Interactive Voter Feedback System

We’re currently exploring ways to make it easier and more intuitive for voters to provide feedback on proposals, especially at the section level.

Inspired by the simplicity and familiarity of social media interactions, we’re imagining a system where each section or paragraph of a proposal is treated like an individual “post,” allowing voters to react quickly using simple icons — perhaps a for general agreement, a for disagreement, and a to flag a critical, potentially deal-breaking issue. Optional short comments could add context without requiring a full reply.

Another idea was to have a HARD NAY option, to act as a one-time-only signal per proposal to indicate that a specific section contains a fundamental, non-negotiable flaw and is the primary reason for their overall rejection of the proposal.

In this new system, voters open the .md version of the proposal from a sidebar, which loads the document in a clean, “Google Docs” style viewer designed for focused reading, that can be expanded full-screen.

This concept is still in early stages, and we’d love to hear your thoughts:

• Would this type of interaction be helpful or distracting?
• Are these reaction types sufficient, or should we consider others?
• What concerns or edge cases should we keep in mind?

Your input will help shape whether—and how—we move forward with this. Let us know what you think!

Subscribing to Changes

A wireframe showcasing a feature like “Notify me if any of these sections change before the proposal period ends” introduces a powerful subscription mechanic. This allows voters to opt in for notifications when specific sections of a proposal are updated.

Such a feature would establish a direct feedback loop between proposers and voters, encouraging voters to revisit the referendum, review changes, and potentially reconsider their stance.

We believe this is a critical upgrade for OpenGov, as it replaces the current informal process—often reliant on lobbying via Telegram, Discord, or other off-chain channels—with a structured, transparent, and automated system for ongoing engagement.

Granular voting on Budget

A wireframe showcasing granular voting patterns on the Budget section. While most of the feedback voting is applied over specific paragraphs and or sections, we feel the budget section should enable granular voting per each budget item.

Results - Proposal Feedback Heatmap

A wireframe showcasing the feedback panel for the proposer - clearly heatmaping the positive and the problematic sections of the proposal.

Architecture Draft

[Editor] (Markdown WYSIWYG)

↓

[Versioning Backend] (Git / IPFS / Database)

↓

[Rendering Engine] (Web frontend with paragraph IDs)

↓

[Feedback Capture] (per ID reaction system)

↓

[Heatmap Analysis] (summarize and visualize engagement)

↓

[Governance Vote Action]

Quick Links & Open Questions - RFC

Link to design prototype Figma:

Figma

Link to wireframes and general idea Figma:
https://www.figma.com/board/LubeAwKnP5fzXihRZlQEsQ/Opengov-Voting-upgrade?node-id=0-1&t=R2U3z2MjQ7cz8iJI-1

Link to voting wireframes Figma:

Figma

This prototype was created within the UX Bounty, as an attempt to elevate user experience on OpenGov and at the same time bring transparency, standards and better OpenGov outcomes.

It is clear the prototype does not provide all the answers, before tackling the feature in depth, we wanted to touch base with the wider Polkadot community and collect feedback on the idea.

With this post we want to hear your thoughts, ideas, constructive criticism, so we can decide whether the idea is worth pursuing further. In the case we receive strong support for the idea, the UX Bounty would continue with UI development of the presented feature, showcasing each UI iteration to the community until consensus is met. At that point, the UX Bounty would execute short user testing on the wireframes prototype, polish the UI and pass the full solution to existing opengov providers (subsquare, polkassembly, etc).

We believe this enhancement will lead to more constructive discussions and better-informed decisions within our governance process.

We welcome feedback and collaboration from the community to refine and implement this proposal.

Best regards,

Nino & Flez @ Polkadot UX Bounty

[Chris_Nifty]

@nino_apillon

These responses rarely include specific feedback on what aspects of the proposal could be improved, leaving proposers in the dark.

Very true. This is a big issue because the proposers don’t know how to improve their proposals.

@nino_apillon

This discourages proposal iterations or rewrites, causing potentially valuable ideas, often just shy of consensus,to be abandoned.

Also true. This happens often because proposers fell discouraged/ unmotivated to improve their proposal.

@nino_apillon

demonstrating that written feedback is currently the exception, not the norm.

Based on experience, getting users to write and leave feedback on proposals is a lot of work. A proposer may spend countless hours getting community members to comment on a proposal. And all that effort could lead to just one comment. This may cause some proposers to feel discouraged or have the wrong impression that voters don’t like their proposal.

@nino_apillon

• Section-Based Voting: Allow voters to provide feedback on specific sections or paragraphs within a proposal.
• Interactive Feedback Mechanism: Implement a system where users can express their stance (e.g., , , ) on individual sections.

Interesting. This could provide valuable insights.

@nino_apillon

Different states of referenda proposal document, addressing version history.

This could be helpful. This would allow proposers to update their proposal based on live feedback while mentioning a trace of the original proposal and older versions. However, I do think that proposers should get feedback about what they can improve on their proposals before going on-chain.

@nino_apillon

Would this type of interaction be helpful or distracting?

Good question. I think it would be worth trying it and seeing what the results would be. I wonder if some voters might not want to or get tired of leaving feedback for every section (even if it’s just one click).

[olanod]

Thanks for sharing your ideas, after many rejections and no feedback I feel the pain points.

I think the proposed improvements would be very valuable, however I would be picky in the technical implementation details and not let OpenGov close itself and be dependent on specific platforms and centralized solutions. We should make some parts direct changes to the on-chain protocol and the bits that don’t make sense to have in the runtime part of an off-chain, yet decentralized, new protocol.

Like I suggested in How to limit altering proposals after they are posted? - #18 by olanod I propose creating a decentralized “Governance API” that is easy to deploy by anyone and uses a decentralized storage backend under the hood, I suggest using Matrix as the backend as it can cover every proposed functionality(e.g. including notifications) and is widely used by many people in the ecosystem(for communications via Element).

To keep runtime changes minimal I would only suggest making the preparation period longer and allow editing the proposed preimage during that time, making it the official period to receive feedback and make adjustments.

The Governance API is in Virto’s roadmap so we would be happy to collaborate in the implementation including any runtime change needed. We use the API to give any DAO their own OpenGov but it would work just the same for the relay chain’s governance.

[Mork]

I’d like to add a suggestion to this:
Indicative voting.

Currently, a proposer’s only guide to whether their proposal needs to change is the ongoing discussion. This is useful and necessary, but hardly an accurate guide. Apart from that, they have a measure of how many votes a proposal has already accrued - but these are votes which will almost certainly not be changed going forwards (unless a new proposal is made), and are from different voters than those yet to vote.

Proposers who are well versed in the opaque power structures of OpenGov have some opportunity to tailor their proposals, between conception and final vote, to fit requirements of large voting blocs.
But this is time consuming for them and near-impossible for most, especially the small useful proposals that many of us are frustrated to see fail so often.

This proposal goes a long way to improve this situation but really, what a proposer needs, is a simple way to gauge in real time the success of their proposal.

So I suggest a norm, backed up in UX/UI for voters, especially large voters such as DAOs and DVs to make 1 or 2 indicative votes over the voting period (ie - ‘I will vote Aye/ Nay, with X vote, Y conviction’; and separately (in discussion), ‘my reasons for this vote are Z: if Z changes, my vote will change’).

There is nothing technical onchain that needs to change to facilitate this - anyone can already change their vote, and it is possible (and many DAOs already do) to state intention in discussion before voting, this is messy UX for a proposer to keep up with to get an incomplete answer as to how their proposal is doing.

What, ideally, would need to be implemented technically is one central non-binding register of indicative votes. If it is integrated with section-based ‘voting’ al the better.

And we would need to propagate this norm, especially among large delegates and whales - which may involve some extra work for them, which they can choose to step up to or not, but hopefully will save time in other ways. Other than that obstacle, large delegates have shown themselves pretty well able to formulate and adopt norms so, especially if supported by UX/UI, this should not be too difficult.

[andrzejSulkowski]

First of all, I am quite new to the Polkadot Ecosystem. Take my comment with a grain of salt.

Standardization of proposer docs
Section feedback system
Additionally I could image seeing here a option to comment on a specific section as well.
Enable Notification
Big like for the Heatmap

Changes I would consider as well are:
→ Integrate comments into the voting flow. Like when someone wants to vote, let them first fill out (or they can skip) a comment section of their reason behind the vote.

I am against the hard Nay. Would keep it simple.
Granular voting on the budget is not something I’d personally use

[florentina57]

First, I would like to applaud this initiative since it addresses many recurrent issues with OpenGov at the moment and offers feasible solutions, many of which I am aligned with.

@nino_apillon

A key problem is the asymmetry in information flow between proposers and voters. Proposers are encouraged to provide in-depth, transparent documents (which often results in long, detailed proposals) while voter responses are limited to binary choices: “Aye” or “Nay.”

It seems like many different ecosystem participants have launched their own ideas/versions/contributions to improve the feedback for OpenGov referenda. A few come to mind, but here are 2 recent examples related to OpenGov (https://kusama.subsquare.io/referenda/561 & https://polkadot.subsquare.io/referenda/1679) and they seem to have been victims of this exact asymmetry you have identified: proposals heavily NAYed and proponents asking for feedback without receiving much of it in return (at least publicly).

If we could easily identify which needs each proposal identifies and how they propose to resolve them, and maybe even categorize them (for example: tags, like on the forum) in a way that a combination of such ideas could, in a collaborative way, result in a real improvement of the OpenGov experience, by generating new proposals with different teams working together towards one goal.

@nino_apillon

Another idea was to have a HARD NAY option, to act as a one-time-only signal per proposal to indicate that a specific section contains a fundamental, non-negotiable flaw and is the primary reason for their overall rejection of the proposal.

I believe that sometimes, part of the lack of feedback provided lies on unwritten rules voters go by in their decision process, and many proponents are unaware of them. Therefore the HARD NAY option could be an easy way to indicate it, while being specific.

@nino_apillon

User Interface: Develop an intuitive UI that integrates with existing SubSquare and PolkAssembly platforms, allowing seamless interaction.

@nino_apillon

We’re currently exploring ways to make it easier and more intuitive for voters to provide feedback on proposals, especially at the section level.

Another reason for the lack of feedback might be the time required to provide such feedback and the ease of doing so. Voters are already spending a lot of time reading and analyzing proposals, so separately taking notes and creating a written comment as feedback might be limited only to certain proposals where their interests are more aligned and not necessarily for every single proposal. So making it more intuitive and integrating it with platforms already being used by voters such as PolkAssembly, Subsquare, OpenSquare or the Discord voting bot are spot on, in my opinion.

@nino_apillon

Privacy: Maintain voter anonymity while ensuring the integrity of feedback.

I noticed that giving direct feedback is sometimes avoided or frowned upon, either for fear of breaking a good relationship or staining a reputation. Exploring voter anonymity is definitely something I would support, and currently there are already some explorations to do this in Kusama. If the feedback was also anonymous maybe more people would be willing to give it freely.

@nino_apillon

Different states of referenda proposal document, addressing version history.

@nino_apillon

This modal view shows users a more in-depth view of version history, with clearly displayed age and github inspired content percentage changes, allowing voters to re-examine significant changes and re-evaluate their vote position.

@nino_apillon

A wireframe showcasing a feature like “Notify me if any of these sections change before the proposal period ends” introduces a powerful subscription mechanic.

Of all the suggestions on this post, this is likely the one I feel could be adopted the quickest and have real impact on the transparency and efficiency of OpenGov. I have never been a fan of proposal documents being a Google Doc and even less of proposals being changed multiple times during the decision period. However, I do commend proponents who listen to feedback and the community and adapt their proposal accordingly. Ideally, in my mind they should resubmit with the changes once the decision period ends but since it can be long (~1 month) then this option of seeing the different versions of the document and having the option of being notified of the changes is definitely a nice compromise solution.

I personally find it hard to follow when complex proposals are rejected and then a 2nd version is posted without a clear outline or definition of the changes between v1 and v2. I would suggest that adding a summary of such changes would give the “version+notify” idea an added value.

@nino_apillon

Granular voting on Budget

This is definitely a valuable contribution, making it easy for voters to provide specific feedback, as they read, same as described above for different sections of the proposal. Once the feedback of many voters is collected and displayed, it will be much easier for all parties to understand which ideas/budget lines/deadlines/etc are appreciated by the tokenholders and which are not.

To enhance this further, I would recommend having a template for proposals that could be widely used by proponents. An idea could be a bit along the lines of what has already been created for RFPs https://www.rfp.fund/launch-rfp . This would also unify the reading experience of proposals, which can also save time and enhance understanding of the proposals.

In summary, I support any UI/UX improvements that can impact the efficiency of decision making in OpenGov, while promoting feedback and transparency. If this can be complemented by privacy and decentralized storage solutions, even better. It makes me hopeful and happy to see each time more realistic ideas proposed by the UX bounty team, while taking into account real user experience from the point of view of different ecosystem members and teams.

[nino_apillon]

@florentina57 thank you very much for this extensive feedback. Since the inception of the idea, we have been talking to different stakeholders and we can say the consensus is to first tackle the document storage, versioning, differences etc - exactly as you laid out.

OpenGov feedback UX improvements are part of newly confirmed UXB proposal, meaning, we can now start planning the implementation details. This means we will prepare feature roadmap and try to define a clean MVP. Once we have this, we will post it here, so we can further extend the consensus.

[bhavyafromPA]

@nino_apillon

Proposers must then wait up to 30 days to learn the outcome. If the referendum fails, the lack of targeted feedback leaves many proposers uncertain about what to change. This discourages proposal iterations or rewrites, causing potentially valuable ideas, often just shy of consensus,to be abandoned.

That’s a very valid argument here. We believe adding the proposed updates would significantly add meaning to participation for proposers and ecosystem as a whole. It would enable constructive criticism , open communication and eventually alignment on ecosystem growth.

[bhavyafromPA]

@andrzejSulkowski

Standardization of proposer docs
Section feedback system
Additionally I could image seeing here a option to comment on a specific section as well.
Enable Notification
Big like for the Heatmap

hey @andrzejSulkowski , those are some very valid inputs. We at Polkassembly offer a add a comment with Vote flow. That does help to some extent.

[polkassembly]

We’re broadly supportive of this initiative. The problems you outline are real, and they match what we see every day on Polkassembly. In practice, proposals tend to fall into a handful of archetypes, but forcing everything into a single, rigid template dulls nuance and reduces authenticity. What’s missing is consistent structure and actionable feedback.

• On our side, we’re building an agent powered by Klara (our AI companion across Polkassembly) that reviews a draft for style, completeness, clarity of data, formatting, and presentation, then gives concrete suggestions to the proposer before they go on-chain.

• In parallel, we’re working with Clarys and a few other teams to index, label, categorize off-chain materials (docs, forum posts, bounty threads) and link them to on-chain context (votes, delegation, identity, and OpenGov parameters). This is hard to do well with current models, but we’re making progress and plan to open-source parts of this work and ship related features on Polkassembly over the next month or two.

We also agree with several ideas in this thread. Standardizing on Markdown with clear version history is a solid step, and the section-level reactions, heatmaps, and “notify-on-change” flows address the current asymmetry where proposers write long documents and voters reply with a binary Aye/Nay. Heatmaps would require substantial effort from voters; and participation is already low. On Polkassembly, we keep voting to minimal clicks and then offer two lightweight follow-ups:

• Add a comment
• Share sentiment (emoji reactions)

Sentiment captures the overall mood but misses nuance. We can expand this area with optional, low-friction feedback flows to add context without overloading users.

Two additions we’d like to offer:

1. Community-curated “Proposal Templates.” Instead of one master template, let the community co-select a small set of archetypes (e.g., research grant, integration, event, infra upgrade) via an off-chain multi-choice voting(and submission) on Polkassembly Off-Chain . Proposers pick an archetype as a starting point, and Klara adapts checks to that context. These templates would become the default authoring flow in Polkassembly (and could be mirrored elsewhere) - these could be made mandatory.

2. Indicative signals. We like the suggestion here for non-binding “indicative votes” from large voters/DAOs/DVs during the voting period, ideally tied into section-level feedback. A simple, central register of intent, kept distinct from the on-chain vote, would give proposers a clearer read earlier, and reduce last-minute fails.

On implementation, we’re mindful of avoiding lock-in. Where possible, we’d favor decentralized storage for the canonical Markdown and a publicly documented interface so multiple front ends can plug in.

If the UX Bounty moves this forward, we can help prototype the Polkassembly side: a small pilot across a few live proposals with Markdown + version history(a version of this is already on Polkassembly, would love to get feedback on improving that), an indicative-signal panel(based on comment analysis from social media, discord chats and everywhere else that people are talking about any proposal).

~ Polkassembly Team