Your repo has 500 open issues. 200 are bugs. 150 are "me too" feature requests that got buried. Your community doesn't know what's popular. You don't know what actually matters. Separate the signal. Give your users a place to vote. See what your community wants.
You opened an issue for a feature request. People thumbs-up it. 47 people thumbs-up it. But the issue keeps getting bumped down by unrelated bug reports and other feature requests nobody cares about. New contributors see the chaos and don't know what's important. Your community doesn't have a voice. You're triage-ing endlessly, trying to figure out what to prioritize.
Issues are for bugs and actual work. They're not a voting mechanism. GitHub added emoji reactions, which is better than nothing, but it's still buried in the noise. You need something separate. A place where feature requests live. Where your community can vote. Where the leaderboard is clear.
Your users care about your project. They want to help shape it. Right now, they have no real way to do that except flooding issue comments with "+1" or opening duplicate issues because they can't find the original.
The signal is lost in the noise. A feature request with 100 thumbs-up sits next to a bug report with 5. You can't tell what's really important. You can't show your community "here's what we're prioritizing and why." You're managing chaos instead of managing a roadmap.
Issues also create duplicates. A user can't search well, so they open a new issue for something that already exists 47 versions down in the backlog. Now you have to consolidate, close duplicates, and manually count votes. That's overhead, not signal.
Finally, there's no feedback loop. You shipped a feature. Did it come from community votes? Your users don't know. GitHub doesn't show the journey from issue to shipped. Your community worked to get their voice heard, but they never see the payoff.
A popular CLI tool gets feature requests scattered across issues: "add config file support," "better error messages," "Windows support." Without feature voting, the maintainer picks based on what was mentioned recently or what's loudest. With voting, they see 200 people want config file support, 50 want better errors, 30 want Windows. The roadmap becomes data-driven. They ship what 200 people asked for, not what sounded good.
React and Svelte get hundreds of feature ideas. Without ranking, maintainers can't tell what's community-critical. With feature voting, they see patterns. "People want better TypeScript support" (200 votes), "better docs" (150 votes), "plugin system" (80 votes). They ship in priority order. The community sees their ideas tracked, voted, prioritized, and shipped. It's transparent. It builds trust.
A programming language gets feature requests for new syntax, better error messages, performance improvements. These are massive decisions. Maintainers want input from their users. Feature voting shows consensus. "95% of votes are for better error messages" is stronger signal than "I read an interesting feature request on GitHub." Voting helps maintainers make big decisions with community confidence.
Features stay in their own space. Bugs stay in Issues. Your community knows where to go.
Most wanted at the top. Everyone sees what matters. No noise, no "+1" chains.
Live in your docs site, README, whatever. Your users don't have to find a separate tool.
Mark features Planned, In Progress, Shipped. Close the loop. Show you listened.
Free tier works for most OSS projects. No gatekeeping. Open source is about community.
Spam protection. One person, one vote. Game-proof. Real signal.
Step 1: Create a board
Hosted on FeatureVoter or embed in your docs. Takes 2 minutes.
Step 2: Link from GitHub
In your issue template, add a note: "Feature requests? Vote here instead."
Step 3: Community votes
You get clarity on what's wanted. They get heard.
Step 4: You ship it
Update status to "Shipped." Close the loop. Thank them.
Free tier: 1 project, 50 votes/month. That's enough for most OSS.
If your project blows up and you hit the cap, Starter is $9/mo. 3 projects, 500 votes/month. Still cheap.
Open source maintainers. We get it. Everything free until you truly can't fit in the free tier.
Your triage time drops. Feature requests are off GitHub Issues. You know what's wanted. Your community feels heard. You can ship features they asked for and actually tell them "we shipped this because you voted for it."
New contributors see a clear roadmap. The project doesn't look chaotic. It looks like someone's steering it. It looks alive.
You maintain momentum. You're not spinning wheels on low-value features. You're shipping what your users actually want.
Yes. Free tier: 1 project, 50 votes/month. That covers most open source projects. If your project grows and you need more boards or voting capacity, Starter is $9/mo (3 projects, 500 votes). We built FeatureVoter with OSS in mind. No surprises, no gatekeeping.
Yes. Absolutely. Drop a link in your README: "Have feature ideas? Vote here." Add it to your issue template: "Feature requests? Go to FeatureVoter instead." Your community will see it. They'll start voting. You'll get clarity on what matters. It's that simple.
Discussions are good for conversations and announcements. But they're not built for voting or ranking. Feature voting is built specifically to rank what your community wants. You see the top 20 feature requests ranked by votes. That clarity doesn't exist in Discussions. You'd have to manually count thumbs-ups and manage threads yourself.
FeatureVoter is platform-agnostic. You can link from your README or docs wherever they live—GitHub, GitLab, Gitea, wherever. Your community votes on FeatureVoter. You manage the roadmap there. You can still use GitHub Issues for bugs. FeatureVoter for feature requests. They're separate but complementary.
Yes. Your users can view the board and vote without an account. Lower friction means more votes. More votes means better signal. We track spam and prevent gaming, so you still get real data. One person, one vote per feature. Even anonymous/low-friction voting is legitimate feedback.
Keep bugs in GitHub Issues. Put feature requests in FeatureVoter. Link from your issue template: "Is this a bug? Report here. Feature idea? Vote here instead." Your community will self-sort. You get clean signal on both fronts. Bugs go where they belong (GitHub). Feature requests get ranked and visible (FeatureVoter).