How to manage user feedback for an open source project
Short answer. Keep GitHub issues as the system of record. Use 👍 reactions and Discussions polls as tiebreakers, not as your roadmap. Bring in the feedback that never reaches GitHub (Discord, email, support tickets) with a weekly pass that copies anything worth tracking into an issue, with a link back to who asked. When something ships, comment on the issue with the release and reply in the place the request came from. If that weekly pass outgrows one person, Modem (our product) does the reading part: it pulls feedback from Discord, Slack, email, and support tools into topics next to the GitHub issues you sync, so one request reported four ways shows up once with everyone who asked. It files a GitHub issue only when you or an automation your team built asks, never on its own, and it doesn't run a voting board or capture GitHub Discussions as feedback.
GitHub retired tasklists on April 30, 2025, and maintainers lost their lightest roadmap view. The job didn't go away. Users still ask for the same feature every month under a new title, a company running the project in production emails instead of filing, and someone still has to decide what ships and tell the people who asked.
GitHub's replacement is sub-issues: up to eight levels of nesting and up to 100 sub-issues per parent, tracked in Projects instead of a Markdown checklist. That covers hierarchy. It doesn't tell you which request matters most, it doesn't see feedback outside GitHub, and it doesn't tell anyone when their request ships. Those are the three gaps this guide covers.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionKeep GitHub issues as the record
Resist standing up a second system of record. Contributors, CI, release notes, and git history already point at issue numbers, and a separate feedback tool fights that instead of using it. A light triage routine is enough for most projects: a needs-triage label on every new issue, a short list of type labels, and a scheduled sweep instead of triaging on arrival. The Kubernetes issue triage guide is a useful reference for the larger version. How to triage GitHub issues at scale covers the mechanics if triage, not ranking, is where your backlog is stuck.
Ranking requests without a board
Reactions. Sort the issue list by 👍 (sort:reactions-+1-desc in the issue search) and you have a ranking with zero setup and no account outside GitHub. It has the same flaw as every vote count: a reaction measures who saw the issue and clicked, not who needs it. A request from a company running your project in production gets the same single click as a passer-by. Treat reactions as a tiebreaker among issues you're already considering. Why +1 comments on a GitHub issue are a bad prioritization signal and how to sort GitHub issues by something better than thumbs-up count go further.
Discussions polls. When you need a decision among named options, a GitHub Discussions poll takes up to eight options, and anyone signed in with read access to the repo can vote. Use it for "which of these three approaches should we ship," not for a standing roadmap.
Who asked, written down. The signal maintainers say they're missing is context: is this from a sponsor, a company running the project in production, or someone who found the repo yesterday? Reactions can't carry that. A comment can. When a request reaches you outside GitHub, add a comment to the issue naming who asked, how they use the project, and a link to the original message. Five weeks later, that comment is your ranking input and your list of who to tell.
When a voting board is worth running
Canny and Featurebase are the two boards that show up most in open source. Both sync with GitHub in both directions.
- Canny links posts to GitHub issues with two-way status sync, on its Pro and Business plans. A status change emails the post's voters by default. Canny offers open source discounts, but doesn't advertise them; ask through live chat or support. See Canny's pricing page for current plans.
- Featurebase pushes board posts to GitHub as issues, automatically or one at a time, and keeps status aligned both ways; completing the GitHub issue emails everyone who upvoted the post. Its free plan is one seat with unlimited end users and feedback, which suits a solo maintainer. Its published discounts cover nonprofits, startups, and education; ask them if your project fits. Check Featurebase's pricing guide for which plan includes the GitHub integration.
On channels: Featurebase's Discord integration adds a /feedback command and an admin-only action to send a Discord message to the board. Canny's Discord integration posts board notifications into a channel, and its Autopilot feature pulls feedback from tools like Slack, Intercom, and Zendesk. Feedback from anywhere those integrations don't cover reaches the board only when someone posts it.
A board is worth running for a community that actively votes. It's a weaker fit when most feedback comes from production users who'll never visit it. Why feature voting boards fail covers the failure modes.
Feedback that never touches GitHub
The request GitHub can't see costs you most: a bug in Discord's #help, a feature gap in an email from a company running the project in production, a ticket in your Jira Service Management queue from a customer with a support contract.
- Discord. Use a forum channel instead of a flat
#feedbackchannel, and pin a four-line bug template (what happened, what you expected, version, a log), so the fifth report of a bug lands as a reply on an existing post instead of more scrollback. How to get product feedback from a Discord community covers the setup. - Email. It tends to come from your most invested users. A shared inbox on the same weekly pass works.
- Support tickets. Jira Service Management is built to close a request, not to tell you what to build next. A resolved ticket doesn't mean the request reached your roadmap, so treat a ticket naming a product gap like a Discord report.
- GitHub Discussions. If you run Discussions, ideas posted there are in GitHub but not in your issue list. Convert the ones you'd act on into issues.
Then give one person a weekly pass: read each channel, answer what you can, and copy anything worth tracking into a GitHub issue, or onto an existing one as a comment, with a link back to the source and who asked. That costs an hour or two a week. The usual failure is that nobody is assigned to it.
Bridging it back without losing who asked
If your team tracks work in Linear, Linear's GitHub Issues sync keeps title, description, status, labels, assignee, and comments matched in both directions, so contributors keep working in GitHub issues. Check Linear's docs or pricing page for which plans include it.
For Discord, email, Slack, and support tickets, the bridge is the weekly pass, and that's the part we built Modem to take over. Modem reads the GitHub repos you switch on (issues and PRs) alongside Discord channels, Slack, email, and support tools like Zendesk and Intercom, and groups reports of the same request into one topic by meaning, not by keyword. "Add a --json flag" becomes one topic carrying the GitHub issue, two Discord messages, and an email, with the people behind each.
When a request is ready to track, ask the Modem agent, in Slack, in Discord, or in the dashboard, to create the GitHub issue. It drafts the title and body, and you can have it include who asked and their quotes. Nothing is filed unless you or an automation your team built asks for it, and in Slack and, by default, in the dashboard an issue on a public repo waits for your approval first: an issue there is a public statement in your project's name, so a person sees it first.
Limits worth knowing for an open source project:
- GitHub Discussions aren't captured as feedback. They don't feed topics, so convert the ones you'd act on into issues.
- Discord users have no email, so a Discord user and the same person's email don't merge into one profile automatically. You can merge them by hand.
- History is 30 days. Connecting a repo backfills open issues from the last 30 days; closed issues aren't backfilled. Discord channels backfill 30 days too.
- No voting board. Modem doesn't give your community a place to post or vote. Priority on a topic is an AI-assigned score that weighs who is affected, how many people and companies, whether it recurs, and whether it's already handled.
GitHub's Copilot app in Slack is another way to file from chat; best tools to turn customer feedback into GitHub issues and best tools to turn Discord messages into GitHub issues compare the options.
Telling people when it ships
This step is what makes the rest worth doing. A maintainer who closes an issue with a bare "done" loses most of the value of shipping it. One who comments "shipped in v2.4, here's the changelog entry" and mentions the people who asked turns a closed issue into a reason to stay.
Closing an issue only reaches people watching it on GitHub. For everyone who asked elsewhere, use the who-asked comments from the weekly pass: reply in the Discord thread, answer the email, update the support ticket. Do it when the release is out, not when the PR merges. How to notify customers when their feature ships covers the routine.
Modem helps with the list, not the sending. With the opt-in Close the loop automation template installed, a merged PR that's directly linked to a topic posts a note to your team's Slack naming who asked, so nobody has to remember. The agent can draft the replies, and in Slack and, by default, in the dashboard a customer reply waits for a person's approval before it's posted to a channel Modem can reply in, such as Discord or Slack. A merge isn't a release, so set the automation's delay or wait for your own release before anything goes out.
When this needs more than discipline
Most projects can run this by hand: reactions for ranking, a Discussions poll for a forced choice, and a weekly pass that copies Discord, email, and support requests into GitHub with a link back to who asked. Under an hour a week for a solo maintainer.
What changes the math isn't issue count, it's channel count, especially when the people funding or running the project in production are on a channel you don't read daily. A hundred GitHub issues and a busy Discord are fine on the manual pass. A feature request from your biggest production user, sitting unread in an inbox, is already lost. Cover the channel those users are on first.