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

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

2 Likes