VoteFirst's Most Wanted list takes the open requests on a project's board and ranks them highest votes first, with a bar for the share of the project's voters standing behind each one. It renders at a page of its own and as a widget for a marketing site.
What counts toward the ranking
Four conditions decide which requests qualify (publicGetTopFeatures, public_top_features.go:120-130):
- It sits in the Suggested column. Once a request moves to In Review, In Progress, Completed or Denied, it drops off the list, even if it is still open to votes somewhere else.
- It has already cleared moderation (
is_approved = true). Nothing pending shows. - It is not hidden and not one of the three seed cards a new project starts with (
notHiddenFeature,notSeedFeature,public_helpers.go:73-81). - It sits on a public custom board, or on no custom board at all (
onAPublicBoard,public_helpers.go:73-76).
Archived suggestions are left out by default, the same way they are left off the hosted board, unless the project owner turns on a setting to show them (public_top_features.go:125-128).
How the order is set
The requests that qualify are sorted pinned first, then by vote count, then by id, and only the top ten are returned (public_top_features.go:132-136). Pinning beats votes outright: a pinned request with fewer votes still shows above a higher voted one that is not pinned.
The count behind the order is Votes, the plain one person, one vote figure. Weighted Votes is a different number, and so is the demand score used elsewhere on the board, which multiplies votes by three, comments by two and views by a tenth; that score belongs to the priority view, not here. Most Wanted answers one question only: which open request has the most people behind it.
The percentage bar
Each request's share is its own vote count divided by the number of distinct voters across every qualifying request, not by every voter the project has ever had (projectVoterCount, public_top_features.go:174-186). A project with few voters moves that percentage fast; a project with many moves it slowly. Where no voter has voted on any qualifying request yet, the share is zero rather than undefined.
What a project's own list looks like, with real numbers
justRead, a reading app built by the people behind VoteFirst, runs its own board on VoteFirst, and its Most Wanted list read today, 2026-10-02, carried 13 open requests with 107 distinct voters behind them, ten of the thirteen shown. The top three: AI features at 39 votes, 36.4 percent of those voters; Read Together at 31 votes, 29.0 percent; StarDict Dictionary Integration at 28 votes, 26.2 percent.
Where the list lives, and where it does not
The page serves at an address of its own, /en/public/top_features/<project slug> (publicTopFeaturesPage, public_top_features.go:27-75), and the same ranking is one of the nine embeddable widgets, called with VoteFirst.topFeatures('#most-wanted', { limit: 5 }) (docs_widgets.html:24-27). The widget's limit trims the list for whoever embeds it; the page itself shows up to ten.
A custom domain does not carry this page. The middleware that rewrites a customer's own domain only recognises three paths, the roadmap, the voting board and a named board (customDomainMiddleware, config.go:852-856), and the Most Wanted address is not one of them. It stays on the project's votefirst.app address regardless of plan.
It is also not in any general sitemap. The one sitemap VoteFirst writes lists the roadmap, the changelog and the Most Wanted page for a single fixed project slug, VoteFirst's own, not a customer's (docSitemap, docs.go:386-397). A customer's Most Wanted page can still be indexed, the same as any other page, if something links to it; VoteFirst does not submit it anywhere on a customer's behalf.
What this does not do
No weighting. The order is plain votes, never Weighted Votes.
No dates or timeline. A request is ranked, not scheduled.
No more than ten shown on the page itself, and no page two.
No custom domain, as covered above.
No ranking by comments or by views on their own. Votes decide the order; the other two numbers are not read here at all.
Next to what other boards publish
Read from each vendor's own developer documentation, 2026-10-02. Canny's widget documentation lists exactly two embeddable widgets, a feedback widget and a changelog widget, with no third widget for a ranked shortlist (developers.canny.io/install/widget). Featurebase's current widgets are a messenger widget, a feedback widget and an updates widget, again with nothing that renders a standalone ranked list. Neither vendor's own documentation describes a page or a widget that does only what Most Wanted does: a short ranked list of open requests by votes and nothing else.
Questions about the list
Does Lite get this page? Yes. Neither the page handler nor the ranking handler checks plan, so a Lite project's board gets the same Most Wanted list a Pro project's does.
Can the embed show more or fewer than ten? Fewer, yes. The widget's limit option trims the list, and the server returns ten at most, so ten is the ceiling for the widget and the page alike (public_top_features.go:134).
Does a request that was never approved show up anywhere here? No. The same moderation gate that keeps it off the public board keeps it off this list.
What happens once a request ships? It moves to Completed and drops off the Most Wanted list the same day, because the ranking only reads the Suggested column. The changelog is where a shipped request goes next.
A CSV export is the other way to see every open request's vote count, in a spreadsheet instead of a page, with columns this list never shows.
14 days, a card at signup, then $9 or $39 a month.