How to Manage Feature Requests in a Discourse Forum

Feature requests keep a product community alive, and they are also the quickest way to turn a tidy Discourse forum into a junk drawer. Ideas land in random topics. Three people ask for the same thing in three different words. Nobody can tell what is planned, what shipped, and what was quietly ignored. Then your best users stop posting, because posting feels pointless.

This guide fixes that. Here is the short answer for how to manage feature requests in Discourse: create one dedicated category with a topic template, enable the Topic Voting plugin, label statuses with tags, merge duplicates, triage weekly, and announce what ships. I wrote it for two readers: members who just want to submit or vote on a request, and admins who run the process. I wrote it from the admin's chair, so expect opinions alongside the facts.

Last reviewed: November 2026. Discourse menu names and plugin options change between releases, so confirm each setting in your own admin panel before you rely on it.

What Counts as a Discourse Feature Request (and What Doesn't)

A Discourse feature request is a topic where a community member suggests a new capability or improvement for a product or the forum itself. Admins typically collect these topics in a dedicated category, let members vote, and label each request with a status so everyone can see what is planned or shipped.

That definition is simple. The hard part is keeping the category honest about what belongs in it.

Feature request vs bug report vs support question

Mixing these three is the main reason request categories rot. Here is how I tell them apart.

If a post describes something that already works as designed, it is a support question. If it describes something broken, it is a bug. Only gaps in capability are feature requests. For more on drawing that line, see this guide on how to separate support from feature requests.

Why requests get messy in forums

Forums reward conversation, and conversation is the enemy of triage. A request topic starts with a clear idea, then drifts into workarounds, side debates, and "+1" replies. Within a month the original ask is buried on page four.

Three forces cause most of the mess:

• No structure at the point of posting. Members write whatever comes to mind, so you get vague asks with no context.
• No visible status. Without a label, silence reads as rejection.
• No owner. If nobody triages, the category becomes a graveyard.

The rest of this article answers each of those three.

Quick Path: Submit or Vote on a Feature Request in Discourse

If you are a member and not an admin, this section is all you need. Many communities run a feature category where staff and users discuss ideas, and Meta Discourse is the best-known example, with the official Discourse team taking part. The Public Knowledge Project also documents how its members propose and discuss requests in its community forum.

Search before you post

Use the search bar first, and try two or three phrasings. People describe the same need in different words, so search for the problem as well as your preferred solution. If a matching request exists, add to it instead of starting a new one.

Vote on an existing request

When the community has enabled voting, you will see a vote control on the topic. Click it to add your vote. Votes are usually limited per member, so spend them on the ideas you care about most. A short reply describing your use case beats a bare "+1," because it gives the team context.

Write a request that gets noticed

A good request is specific and short. Use this mini-template:

1. Problem: What are you trying to do, and what blocks you?
2. Current workaround: What do you do today?
3. Desired outcome: What would "solved" look like? Describe the result, not the interface.
4. Who is affected: Just you, your team, or every member of a certain type?
5. Urgency: Nice to have, or blocking your work?

Compare two titles. "Better notifications" tells a maintainer nothing. "Let me mute one category's email digest without muting the whole forum" tells them exactly what to evaluate.

How to Set Up a Discourse Feature Request Category

Here is the numbered version, which is also the setup path I recommend:

1. Create the category and write clear guidelines.
2. Add a category topic template.
3. Set permissions.
4. Add tags for status and product area.
5. Enable voting (covered in the next section).
6. Announce the guidelines and pin them.

Let's break it down.

Step 1: Create the category and write clear guidelines

In the admin area, create a new category with a name members will recognize at a glance, such as "Feature Requests." Skip clever names. Then write a category description that answers three questions: what belongs here, what does not, and what happens after someone posts. Some communities call this space a feedback category instead. The name matters less than the clarity of the rules.

Pin an "About this category" topic that links to your bug and support categories. Pointing people to the right place is the cheapest moderation you will ever do.

Step 2: Add a Discourse feature request template

Discourse lets you attach a topic template to a category, so the composer opens pre-filled. Check your admin panel for the exact setting label, since wording varies by version. Paste in the template below.

## Problem
What are you trying to do, and what is getting in the way?

## Current workaround
How do you handle this today?

## Desired outcome
What would a good result look like?

## Who is affected
Just me / my team / all members of type ___

## Urgency
Nice to have / Important / Blocking

If I had to pick one change with the best return in the whole workflow, this is it. Structured posts are faster to score, easier to merge, and much easier to summarize later.

Step 3: Set permissions and who can post

Decide who can create topics and who can reply. Most communities let all members do both. Some restrict topic creation to a trust level so brand-new accounts cannot flood the category. Discourse's trust level system fits this job well. Limit staff-only actions, such as changing statuses and closing topics, to moderators or a dedicated group.

Step 4: Add Discourse status tags and area tags

Create a small, fixed tag set. Two families work well:

• Status tags: under-review, planned, in-progress, shipped, declined
• Area tags: one per product area, such as mobile, api, billing

Restrict status tags to staff. Otherwise members will tag their own requests "planned," and trust evaporates.

Recommended category settings

How to Enable the Discourse Voting Plugin

Voting turns a pile of opinions into a rough demand signal. Discourse offers it through the Topic Voting plugin, which lives in the discourse-topic-voting repository on GitHub. Plugin names, settings, and availability can differ by hosting plan and version, so verify what your install provides.

Install and enable Discourse Topic Voting

On self-hosted Discourse, you add plugins through the app configuration and a rebuild. On hosted plans, the plugin may already be available to switch on. Check your admin panel's plugin list, then enable it site-wide.

Enable voting per category

Voting is normally switched on for specific categories, not the whole forum. Turn it on for your Feature Requests category only. Votes on support threads just add noise.

Vote limits by trust level and how to explain them

The plugin caps how many votes members can hold at once, and those caps can vary by trust level. Look at the plugin's settings in your admin panel for the exact options. Whatever the numbers, explain them in your pinned guidelines in plain language: "You have a limited number of votes. Remove a vote from a shipped or declined request to get it back."

A scarce vote carries meaning. If votes were unlimited, everyone would vote for everything, and the ranking would tell you nothing.

Why votes aren't a roadmap

I treat votes as one input, never the decision. Three biases distort them:

• Loud minorities. A passionate group can outvote a quiet majority.
• Age. Older requests pile up votes simply by existing longer.
• Visibility. Requests that surface in search or get pinned collect votes others never see.

Use the vote count as a "reach" estimate in your scoring rubric, covered below.

Tracking Status: A Request Workflow for Discourse

Status is what separates a request process from a suggestion box. Members forgive "no." They do not forgive silence.

Recommended statuses

The lifecycle flows one way. A new request enters as Under review, then moves to Planned or Declined. Planned moves to In progress, and In progress ends at Shipped. A declined request can reopen if circumstances change, but treat that as the exception.

Implementing statuses with tags or categories

Tags beat categories for status. A topic can live in only one category, so moving it between "Planned" and "Shipped" categories breaks its link to the original request area. Tags sit on top of the category, filter cleanly, and leave the topic in place. Use a category only when you need different permissions, such as a staff-only "Triage" area.

Put the status in the topic title only if your community is small and wants visual clarity. Otherwise the tag is enough.

How to Merge Duplicate Topics in Discourse

Duplicates split votes and dilute discussion. Handle them fast, because every day a duplicate lives, it pulls votes away from the main request.

Spot duplicates early

Scan new topics at every triage. Search with the nouns in the title, not the whole sentence. Discourse also suggests similar topics while a member composes a post, so keep that feature on and mention it in your guidelines.

Merge topics and redirect voters

How to merge duplicate requests:

1. Pick the strongest topic as the canonical one, usually the oldest or the clearest.
2. Open the duplicate and use the topic admin tools to merge it into the canonical topic. Menu labels vary, so look for a merge or "move posts" option.
3. Confirm the merged posts landed in the right place and that the title still describes the request.
4. Post the duplicate reply macro below.
5. Make sure voters on the duplicate know to vote on the canonical topic. Voting behavior after a merge can vary, so test it with a throwaway topic before you rely on it.

Reply macros

Keep these in a pinned staff note so every moderator sounds the same.

Duplicate: "Thanks for the suggestion. This is already being tracked in. I have merged your post there so the discussion stays in one place. Please add your vote on that topic."

Declined: "Thanks for taking the time to write this up. We have decided not to build this, because [specific reason]. If your situation changes or you have new information, reply here and we will take another look."

Needs more info: "This could be a good fit. Can you tell us what you are trying to accomplish and how you work around it today? That helps us judge how many people it would help."

How to Triage Feature Requests Weekly

Triage is a routine, not a project. If you wait until you "have time," the backlog wins.

A 30-minute triage routine

Run this every week, same day, same slot:

• Open the category filtered by the under-review tag (5 min)
• Move bugs and support posts to the right category (5 min)
• Merge duplicates and post the macro (5 min)
• Score the remaining new requests (10 min)
• Update statuses and reply on anything declined or planned (5 min)

Scoring rubric with a worked example

Beyond votes, I score each request on four factors from 1 (low) to 5 (high). The rubric borrows from the popular RICE prioritization framework described by Intercom, simplified for forum use.

• Impact: How much does it help the people it affects?
• Reach: How many members want it? Use the vote count as a guide.
• Effort: How hard is it to build? Score 5 for easy, 1 for very hard, so higher is always better.
• Strategic fit: Does it move the product where you want it to go?

Add the four scores. The total is out of 20.

These numbers are illustrative, not benchmarks. Set your own thresholds, then stick to them so decisions feel consistent to members.

Separate bugs and support from requests

Put a line in the template and the pinned guidelines: "Something broken? Post in Bugs. Need help? Post in Support." When a miscategorized topic shows up, move it and leave a short note. If you run a larger ticketing stack, the handoff can go further. Teams that track engineering work might send accepted items to Linear; see this walkthrough on Linear feature requests, or the GitHub Issues roadmap workflow if your engineers live in GitHub.

How to Close the Loop When a Request Ships

Closing the loop is the cheapest retention tactic in community management. A member who sees their idea ship often becomes a loyal advocate.

Update status and post in a changelog topic

When a request ships, change the tag to shipped, then post an announcement. I keep one pinned "What's new" topic and add a dated reply for each release, linking every shipped request. If you want a dedicated page outside the forum, these changelog tools are worth comparing.

Notify voters and the original requester

Reply on the original topic with a short note on what changed. Members who posted in the topic or are watching it get a notification. Mention the original requester by username. Whether voters receive a separate notification depends on your plugin version and notification settings, so test it before promising it.

Link to the changelog and roadmap

End every shipped reply with a link to the changelog topic and the roadmap, so readers can see what comes next.

Building a Discourse Roadmap and a Public Roadmap for Discourse

Here is the honest part. Discourse is a forum, not a roadmap product. It handles conversation and votes well, but it has no dedicated public roadmap board out of the box.

Native options

Two approaches work:

• Pinned roadmap topic. One staff-maintained post with sections for Planned, In progress, and Shipped, each linking to the request topics. Edit it at every triage.
• Tag-filtered views. Share links to the category filtered by the planned or in-progress tag. Members can bookmark these, and they update themselves.

Limits of native Discourse

• Statuses are manual tags, so nothing enforces consistency.
• There is no kanban-style public board.
• Reporting on votes over time takes custom work.
• Requests from outside the forum, such as chat apps, never appear.

External roadmap tools

If you outgrow the native setup, dedicated tools such as Canny and Upvoty are built around request boards. I run RoadmapAI, the publisher of this guide, so weigh my view accordingly. RoadmapAI is built around Discord, with feature request tools that capture, track, and vote on requests where Discord communities already talk. It does not integrate with Discourse today, and Slack, Intercom, and Zendesk support is listed as coming soon. If your community also lives in Discord, its public roadmap software gives you the board Discourse lacks, and you can check plans on the pricing page.

My view: stay native while your volume is manageable and your audience lives in the forum. Add a dedicated tool when you spend more time maintaining the roadmap post than reading requests.

Automation, Reporting, and AI Help

API and webhooks

Discourse has a REST API and webhooks. Use them to push new request topics into your issue tracker, post to an internal chat channel, or log statuses in a spreadsheet. Keep the first automation small: "new topic in Feature Requests creates a notification for the triage owner."

Data Explorer for top-voted open requests

The Data Explorer plugin lets admins run SQL queries against the forum database. A useful query idea: list topics in the Feature Requests category that carry no shipped or declined tag, sorted by vote count descending. Run it before each triage. Table and column names depend on your version and plugin, so build the query from the schema browser inside Data Explorer instead of copying one from a forum thread.

AI summarization and duplicate detection

Discourse AI offers assistance such as summarizing long topics. Check what your plan includes before you build a process around it. Realistically, summaries of long request threads save time. Treat any automatic duplicate suggestion as a hint that a human confirms, never as a merge button. For a wider survey of tools, see these AI feedback tools.

Collecting Discourse Community Feedback Across Discourse and Discord

Why requests live in several places

Many communities run a Discourse forum for long-form discussion and a Discord server for fast chat. Feature ideas show up in both, plus email, Slack, and support tickets. If you only watch the forum, you miss the loudest demand.

A single intake workflow

Pick one system of record and funnel everything into it:

1. Name the system of record, for example your Discourse category.
2. Tell chat members to post ideas in a request channel, or react to flag them.
3. Once a week, copy valid ideas into the forum template, or link back to the forum topic.
4. Reply in chat with the topic link so voting stays in one place.

If Discord is a major channel, learn how to collect feature requests from Discord, or try a Discord feedback bot to turn chat into structured requests. Teams on other channels can look at guides for Slack feature requests, Telegram feature requests, Zapier routing, or a feedback email to roadmap workflow. Open-source projects may also weigh GitHub Discussions feature requests as an alternative home.

When you store member feedback, remember that names and posts are personal data. The GDPR portal is a sensible starting reference if you serve EU members.

Common Problems and Fixes

Feature Request Management Checklist

Setup

• Dedicated Feature Requests category created
• Guidelines written and pinned
• Topic template added
• Permissions set, status tags staff-only
• Topic Voting enabled for this category only
• Bugs and support categories linked in guidelines

Weekly

• Move bugs and support posts
• Merge duplicates with the macro
• Score new requests
• Update status tags
• Reply to every declined request with a reason

On release

• Tag the request shipped
• Post in the changelog topic
• Mention the original requester
• Update the roadmap topic

Frequently Asked Questions

What is a feature request in Discourse?

It is a topic suggesting a new capability or improvement, usually posted in a dedicated category where members can discuss, vote, and see a status label.

How do I create a feature request category in Discourse?

Create a new category in the admin area, write guidelines, add a topic template, set permissions, and add status tags. The setup section above has the full steps.

How do I enable voting on Discourse topics?

Enable the Topic Voting plugin, then switch voting on for your Feature Requests category. Confirm the exact setting names in your admin panel, since they vary by version.

How many votes does each user get?

The plugin limits votes per member, and the limit can vary by trust level. Check the plugin's settings for the values on your site, and explain them in your guidelines.

How do I write a good feature request?

State the problem, your current workaround, the outcome you want, who is affected, and how urgent it is. Search first so you add to an existing request instead of duplicating it.

Should I use tags or categories for request status?

Use tags. They keep the topic in its original category, filter cleanly, and can be limited to staff.

How do I merge duplicate feature requests?

Choose the strongest topic as canonical, merge the duplicate into it using the topic admin tools, and post a short reply pointing voters to the surviving topic.

How often should I triage requests?

Weekly works for most communities. A fixed 30-minute slot beats an occasional big cleanup.

Can I build a public roadmap from Discourse?

Partly. A pinned roadmap topic and tag-filtered links work, but Discourse has no native roadmap board. Dedicated tools fill that gap.

Can AI help with duplicates and summaries?

Discourse AI can help summarize long threads, depending on your plan. Treat duplicate suggestions as hints that a person reviews before merging.

Next Steps

Start small. This week, create the category, paste in the template, and enable voting. Next week, run your first 30-minute triage and publish the roadmap topic. Within a month, announce your first shipped request, and watch how the tone of the forum shifts when members see their ideas move.

Sources

• Meta Discourse community forum, Discourse
• discourse-topic-voting plugin repository, Discourse on GitHub
• Understanding Discourse Trust Levels, Discourse Blog
• Discourse API documentation, Discourse
• RICE: Simple prioritization for product managers, Intercom
• PKP Community Forum, Public Knowledge Project
• General Data Protection Regulation information portal, GDPR.eu