How to manage user feedback for an open source project
GitHub sunset tasklists in April 2025, and open source maintainers lost their closest thing to a built-in roadmap view. The tasklist is gone; the underlying job isn't. Users still ask for the same feature every month, still email when GitHub feels wrong, and someone still has to decide what ships and tell the people who asked.
GitHub's own replacement is sub-issues. Each issue gets a dedicated section for related work, up to eight levels deep, tracked in Projects instead of a Markdown checklist. That covers the hierarchy tasklists gave you. Ranking requests and telling people when something ships stay open. Those are the two gaps this guide answers.
None of that requires replacing GitHub, just being precise about what it handles natively and where the other channels (email, Discord, a customer's Jira instance) need a deliberate bridge back in.
“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 NotionGitHub issues already anchor the project
Resist the urge to stand up a second system of record. Contributors, CI, release notes, and git history already point at issue numbers; a separate feedback tool fights that gravity instead of using it. The Kubernetes triage playbook scales down cleanly. A default label for untouched issues, a small taxonomy, a scheduled sweep instead of triaging on arrival. The mechanics are in how to triage GitHub issues at scale, useful if triage, not voting, is where your backlog is stuck.
Where voting belongs
The cheapest option is already in the product you're using. Sort any issue list by sort:reactions-+1-desc and 👍 reactions become a ranking, zero setup, no account outside GitHub required. It has the same failure mode as every voting mechanism. A reaction measures who saw the issue and clicked, not who needs it most. Treat it as a tiebreaker among issues already under consideration. Why feature voting boards fail covers why that's true of any voting surface, board or reactions alike.
GitHub Discussions polls are a step up when you want an actual decision. Post up to eight options, and anyone signed in with read access can vote. You can't close a poll at a set time, restrict who votes, or see who voted after the fact. Fine for "which of these three approaches should we ship," poor for anything needing an audit trail.
For a standing public roadmap outside GitHub, Canny and Featurebase show up most in open source. Both verify the same way on their own integration pages. The sync back to GitHub is automatic but one-directional. Push a Canny post to GitHub as a linked issue, and closing that issue flips the Canny post's status automatically; Featurebase auto-emails everyone who upvoted a post once you complete the linked GitHub issue. Neither automates the reverse. Turning a Discord ping or a support email into a linked board post is still a person's job. Canny extends open source discounts, only if you ask over live chat; Featurebase's discount is scoped to nonprofits, so most small projects run its standard free tier instead. The failure modes in why feature voting boards fail still apply. A board is worth running for a community that actively votes, and a weaker fit when feedback comes mostly from production users who'll never find it.
Feedback that never touches GitHub
The cost to a maintainer is the request GitHub can't see. A bug in Discord's #help channel, a feature ask buried in a support email, a formal ticket in the Jira instance a customer's contract requires.
In Discord, pin a four-line bug template ("what happened, what you expected, version, a log") to a forum channel rather than a flat #feedback channel, so the fifth report of a bug lands as a reply on an existing post instead of more scrollback. Assign one person a weekly pass to read it, answer it, and copy anything worth tracking into a GitHub issue with a link back to the thread; how to get product feedback from a Discord community covers the full setup. Email tends to arrive from your most invested users, running the project in production rather than filing a first issue, so a shared inbox on that same weekly pass works too, unautomated. Jira is different because Jira Service Management is built to close a request, not tell you what to build next. A closed ticket doesn't mean the request reached your roadmap, so treat a JSM ticket naming a product gap like a Discord report, copied into GitHub by hand.
Syncing it back without losing who asked
The manual version above is fine at low volume. It costs an hour or two a week, and the failure mode is nobody being assigned to do it.
If your internal tracker is Linear, Linear's native GitHub sync keeps title, status, labels, and comments matched both ways on every plan, so contributors still just work in GitHub issues.
For the email, Discord, and Jira paths without a native bridge into GitHub, that's the gap we built Modem to close. It reads your connected GitHub repo the same way it reads Discord, email, and Jira, clusters the same request wherever it shows up, and keeps who asked attached to the topic. "Add a --json flag" becomes one topic carrying the GitHub issue, the two Discord messages, and the enterprise Jira ticket, plus the account behind each. Modem doesn't auto-file new GitHub issues from a Discord message or an email; it removes the read-everything, find-the-duplicate, reconstruct-who-asked work underneath that step. GitHub's own Copilot app for Slack does the filing itself, turning an @GitHub mention into a structured issue with title, body, and labels; best tools to turn customer feedback into GitHub issues and best tools to turn Discord messages into GitHub issues cover the rest.
Telling people when it ships
This is the step that makes the rest worth doing. A maintainer who closes an issue with a bare "done" loses the retention value of shipping it; one who comments "shipped in v2.4, here's the changelog entry" and tags the thread turns a closed issue into a reason people stay. Recording who asked so the notification is automatic is the mechanic in how to notify customers when their feature ships, with GitHub handles standing in for email. A pinned tracking issue or a maintainers-only Announcements post is enough.
When this needs more than discipline
Most projects can run this by hand. That's sort:reactions-+1-desc for ranking, a Discussions poll for a forced vote among named options, and a weekly pass copying anything from Discord, email, or a customer's Jira into a GitHub issue with a link back to the source. Under an hour a week for a solo maintainer.
What changes the math isn't issue count, it's channel count with a paying customer on one of them. A hundred GitHub issues and a chatty Discord are fine on the manual pass. A $50k/year customer's feedback stuck in an unread Jira ticket is already lost, whether or not anyone's counted the GitHub issues yet. That's the gap worth closing first. The vote count on your top issue was never the constraint.
