Topic voting category for public feature requests
Keep feature requests in a dedicated voting category so demand gathers on one public thread instead of splintering across duplicate asks.
Why this can grow a startup
A public forum gets messy fast when feature requests arrive as plain conversation. The same idea gets posted three times, support cannot point prospects to one live record, and product loses the compounding signal of visible demand. Discourse Topic Voting gives a cleaner lane by letting specific categories run on votes. That makes each request page work harder. It becomes a demand counter, a place for clarifications, and a public artifact sales or success can reuse. The gain is not just prioritization. It is a more legible product story in public.
Company example
Discourse's official Topic Voting plugin lets admins enable voting on topics inside specified categories.
Source and metric
Source: Discourse Meta: Discourse Topic Voting
Topic Voting gives users the ability to vote on topics in a specified category.
Source discovered: May 29, 2026
When to use it
Use this when Community, Product, Sales is relevant to feature requests, community signal, roadmap trust and you can run a bounded test with a free budget.
When not to use it
Do not use it as a substitute for customer evidence, a clear owner, or a measurable stop condition. Local platform rules and market behavior still need checking.
Founder checklist
- Read Discourse Meta: Discourse Topic Voting and identify what is directly supported.
- Choose one channel context: Community, Product, Sales.
- Define the test around Topic Voting gives users the ability to vote on topics in a specified category..
- Set an owner, evidence window, and stop condition before launch.
Explore the context
Apply this with an operator
Build creator and community systems around real incentives, trust, and repeat participation.