The best way to collect product feedback from GitHub Discussions

Short answer. For many open-source projects, GitHub Discussions plus GitHub issues is enough, and it costs nothing. Give feedback its own category, let people upvote, name one person to triage it, and use GitHub's "Create issue from discussion" for each request you decide to build. That keeps Discussions as the place ideas get raised and Issues as the place work is tracked. You need more only when the same request also arrives elsewhere (Slack, Discord, support tickets, calls) or when the people planning work never open GitHub. The options then are a Slack subscription to a Discussions category, a community tool such as Common Room, or a webhook or GraphQL script you write. Modem (our product) is not one of them for Discussions: it does not ingest GitHub Discussions. It reads GitHub issues and pull requests plus the Slack, Discord, email and support side, so the honest fit is to convert the Discussions you act on into issues in a repo you've connected, or to subscribe a Slack channel to a Discussions category and let your team discuss it there.

Discussions does more structuring than most teams use. The gap is one step later: a tidy board still lives inside GitHub, read by whoever remembers to check it, disconnected from the Slack thread and the support ticket that say the same thing in other words. This guide covers what GitHub already gives you, how to run it, and the ways to get the signal out. We build Modem, so read its section with that stake in mind. It is fourth in line here because for Discussions specifically it is a workaround, not a native fit.

First decide: is Discussions your backlog or an input?

Two models work, and mixing them is what makes boards messy.

• Discussions as the backlog. Requests live and get decided there. Upvotes are the demand signal. This is simplest, and fine for a project with a modest volume and a community that lives in GitHub.
• Discussions as a staging area. Unconfirmed reports, questions and ideas start in Discussions, and only confirmed work becomes an issue. One public thread from an open-source project that works this way gives its reasons: it separates unconfirmed items from tracked work, and it avoids the pressure of a visible issue count. It also lists the costs: triage lands on a couple of maintainers, and some users still open issues directly. (The thread.)

Most teams that want product decisions, not just a forum, end up with the second model: Discussions is where requests are raised, and the issue tracker or your planning tool is where they are counted and scheduled.

1. GitHub Discussions, set up well

Before adding anything, use what is already there.

• Categories have formats. Each category is open-ended, question and answer, announcement, or poll. The defaults are Announcements (announcement), General (open-ended), Ideas (open-ended), Polls (poll), Q&A (question and answer) and Show and tell (open-ended). Ideas is a category, not a separate format. In an announcement category only people with maintain or admin permission can start a discussion, while anyone can comment. See GitHub's docs on managing categories.
• Keep questions and requests apart. Questions go in Q&A, where a reply can be marked as the answer by the discussion's author or anyone with the triage role or higher. Requests go in Ideas. When a question turns into a feature request, start a new, linked post in Ideas so the request can be counted on its own.
• Upvotes count demand. Discussions and top-level comments can be upvoted, not nested replies. The discussion list can be sorted by Top, and so can top-level comments. See participating in a discussion.
• Polls settle choices. A poll category takes up to eight options. On a public repo anyone can see the poll, but only logged-in users can vote. (Announcement.)
• Labels show status. A label such as "tracked in backlog" tells voters their request was seen.

Natively, upvotes are the only counting signal. GitHub's Discussions docs we checked describe no priority score, no duplicate merging, and no way to link a request to the customers or accounts behind it, or to count the same request across channels. For a project whose community lives in GitHub, that is often fine.

A routine that keeps the board from going stale

1. Name a triager. One person, or a small rotation, reads new discussions on a schedule. Triage that belongs to everyone belongs to no one.
2. Review by Top. Sort Ideas by Top once a week, and read the comments on the leaders for the real problem behind the request.
3. Create an issue for what you will build. From a discussion, a person with triage permission can create an issue. The discussion's text and labels carry over, and the discussion is not converted or deleted. It stays where it is, so put the issue link in a comment on it.
4. Say so on the discussion. Comment with the issue link, add your "tracked" label, and later comment again when it ships.
5. Say no out loud. Closing a discussion with a reason is better than leaving it to age.

2. GitHub for Slack and Microsoft Teams

GitHub's own app can subscribe a channel to a repo's discussions:

/github subscribe owner/repo discussions

It posts a notification when a discussion is created or answered. Since 2023 you can limit it to chosen categories, which is the useful form for feedback:

/github subscribe owner/repo discussions:{category:"Ideas"}

The Slack app needs read permission on discussions, and an organization owner has to approve that permissions update. The command and events are in GitHub's Slack and Teams announcement, the category filter changelog and the Slack docs.

It is a notification, not a tracker. Nobody records which discussions got a follow-up, and the message scrolls away like any other post. It works best as the way your team notices new Ideas, with replies in the thread where the team decides what to do.

Where it fits: teams who need eyes on new discussions without adding a tool.

3. Common Room

Common Room's GitHub integration creates members and activities for people who post or reply in a Discussion, alongside stars, forks, issues and pull requests. It reads Slack, Discord, Reddit and Discourse too, so one person's activity sits on one timeline. It also has GitHub triage playbooks, including real-time Slack alerts for GitHub activity from your customers and from organizations matching your ideal customer profile. Its current positioning is buyer and pipeline intelligence as well as community, and its plans are on its pricing page.

Common Room is built around who is active and which accounts matter. We did not find documentation saying whether it groups Discussions into deduplicated requests, so check that with the vendor if it is your need.

Where it fits: open-source and developer-tool companies building a picture of which people and accounts are active across GitHub, Slack, Discord and Reddit, Discussions included.

4. Modem

Modem reads the issues and pull requests in the GitHub repos you switch on, and treats issues as customer feedback in the same way as a Slack thread, a Discord message, a support ticket or an email. Reports that describe the same problem in different words are grouped into one topic, and the topic keeps the original messages and the people and companies behind them. PRs attach to topics as context about what your team shipped.

What it does not do. Modem does not ingest GitHub Discussions. Modem's GitHub docs say they are not yet supported. A discussion never becomes a message or a topic. We have not confirmed whether Modem's agent can read a Discussion on request, so don't count on it.

What to do instead. Two workarounds, both using things that exist today:

1. Create an issue from the discussion. When you decide to act on a request, use GitHub's "Create issue from discussion" in a repo you have connected to Modem. The discussion stays in place, and the issue is read like any other issue in that repo. Put the original poster's handle and a link to the discussion in the issue body so your team can trace it. That text doesn't make the poster a participant Modem can attribute the request to, and an issue opened by a teammate with no outside participant may not start a customer topic on its own, so check that the request landed on a topic (it may join an existing one) and ask the poster to comment on the new issue if you want them counted. Modem backfills open issues from the last 30 days when you connect a repo, and closed issues are not backfilled.
2. Subscribe a Slack channel to a Discussions category. Modem reads Slack channels it is subscribed to. Bot messages do reach Modem's ingest, but Modem's docs advise keeping bot-notification channels out, and we have not tested how well a GitHub notification alone becomes a useful topic. If you try it, use a channel where your team replies to each notification, since human replies are what carry the context.

If you work in a public repo, remember that anything you paste into a public issue is public: keep customer names, emails and private links out of issue bodies and in your own log.

Why we built it this way. Product signal gets split from engineering work: a user files a GitHub issue, the same complaint lands in Slack and support, and nobody can connect either to the PR that fixed it. Modem's job is to put those in one place, so it starts from the sources where customers write and from the issues and PRs where work is tracked.

Where it fits: a company or project whose feedback arrives across GitHub issues, Slack, Discord and support, and where seeing everything about one request together matters. Where it doesn't: a community whose feedback lives only in Discussions, where nobody converts threads to issues. For that, the native routine above, or a tool that reads Discussions, is the better answer. Modem also doesn't have a public voting board.

5. Webhooks and Actions

GitHub sends discussion and discussion_comment webhook events. The discussion event covers created, edited, deleted, transferred, pinned, unpinned, labeled, unlabeled, locked, unlocked, category changed, answered and unanswered. discussion_comment covers created, edited and deleted. GitHub Actions can trigger on the same events, for example on: discussion: types: [created, answered], so a small workflow can post new Ideas into a spreadsheet, a ticket or a Slack channel.

Zapier and n8n are the usual no-code routes, and neither lists a native Discussions trigger as of 2026-10-05. Zapier's GitHub trigger list did not show one in what we checked, and n8n's GitHub Trigger node did not list a discussion event, with feature requests open on its forum (one, two). That is a gap in their trigger lists, not a limit on what you can build: both can receive a generic webhook, and you can point a GitHub webhook at it.

It is more setup than the options above, and real-time once running.

Where it fits: teams with someone comfortable writing a small Action or webhook receiver who want Discussions activity routed somewhere specific.

6. A scheduled GraphQL export

GitHub's GraphQL API exposes a repository's discussions, categories and comments. Repository.discussions can filter by category and answered state, and each discussion has an upvoteCount and an answer. A script on a cron can pull what's new into a spreadsheet for a weekly read. We found no REST endpoint for repository discussions, so GraphQL is the documented read path, and the token needs permission to read discussions.

It is batch, and it only helps if someone reads the export instead of letting it pile up.

Where it fits: early-stage projects where a weekly pass is enough and nobody wants another integration.

The short version

Feedback platforms such as Productboard, Aha!, Featurebase and FeatureOS also come up in AI answers on this question as having GitHub integrations. We did not verify whether any of them reads Discussions rather than issues, so check before you buy.

How to choose

Start with what already works. If a clean Ideas category, upvotes, a named triager and "Create issue from discussion" give you a board your community uses and a backlog your team trusts, stop there. That is enough for many open-source projects.

If your team needs to notice new ideas, add the Slack subscription in option 2, filtered to Ideas. If the question is who in your community is active and which accounts they belong to, look at Common Room. If you need Discussions routed to a specific system, write the webhook or the scheduled export.

If your feedback also arrives in Slack, Discord and support, and you want it counted with your GitHub issues and tied to the PRs that fixed it, that is where Modem fits, with Discussions converted to issues on the way in. Our guides on managing user feedback for an open source project and turning customer feedback into GitHub issues cover that side in more depth.

FAQ

Can you upvote replies in GitHub Discussions?

You can upvote discussions and top-level comments. GitHub's docs describe upvoting for those two, and nested replies are not described as upvotable. Both discussions and top-level comments can be sorted by Top.

Does "Create issue from discussion" convert the discussion?

No. It creates a new issue from the discussion and leaves the discussion in place, so link the two with a comment. A person with triage permission can do it.

Does Zapier or n8n have a GitHub Discussions trigger?

Not that we found. As of 2026-10-05 neither tool's GitHub trigger list included a Discussions event. Both can receive a generic webhook, and GitHub sends discussion and discussion_comment webhooks, so you can still connect them.

Does Modem read GitHub Discussions?

Modem does not ingest Discussions. It does read GitHub issues and pull requests in repos you connect, so the workaround is to create an issue from each discussion you act on, or to subscribe a Slack channel to a Discussions category and discuss it there.

Is GitHub Discussions enough for product feedback?

For many open-source projects, yes, with a feedback category, a named triager and a habit of turning accepted requests into issues. It stops being enough when the same request also arrives in Slack, Discord or support tickets and you need to count it across channels.