We Audited 29 Public Feedback Boards. Here's How Long Top-Voted Requests Sit Open.

The headline numbers

Across the 29 boards we analyzed 342 top-voted posts. Sorted into three buckets by vendor status: 9 delivered, 1 declined, and 332 open and not delivered.

The last number needs its composition stated plainly: the 219 includes all 112 open GitHub issues, which structurally cannot carry a vendor status because GitHub has no status field. So look at the hosted feedback boards alone, where vendors have a status feature and choose whether to use it: 107 of 220 open top-voted requests, about 49%, carry no status of any kind. If most open requests carried a "planned" or "in progress" label, you could argue the boards are working and the queue is just long. Instead, on half of the hosted boards' top requests, the vendor never told the voters anything.

And the two ~93% figures deserve their denominators up front: they are computed only over boards whose #1 request is at least one year (28 boards) or two years (27 boards) old, so young boards cannot fail a test they have not had time to take.

How long top-voted requests have been open

This is the age distribution of the 285 posts behind the median: each board's ten most-voted requests that are open and not delivered, binned by years since the request was created.

Read that again: the single biggest cohort of top-voted open requests is six to seven years old. Only 10 of 285 are less than a year old. These are not fresh requests still working through a queue. They are requests that entire product strategies have been written, executed, and rewritten around while they sat there.

The #1 request on every board

One row per board: the single most-voted request across all statuses, with the vendor's own status and our bucket. Every request title links to the live source post; every company name links to the board. Sorted by count; units (votes vs GitHub reactions) are labeled per row and are not comparable across rows. Note that two boards' #1 requests are delivered (ClickUp's Subfolders, in beta, and Morgen's task tags): the data includes them because the audit includes every verified board, whatever it shows.

The full dataset behind this table, including all 342 posts, the 45 dropped candidate boards with reasons, and the complete status map, is published at /data/board-audit.json.

Methodology

Where the candidate list came from

We compiled 74 candidates before seeing any outcome data: well-known customers of hosted feedback tools, vendor showcase pages, and official feature-request repos of major open source projects. Every board that passed official-verification went into the dataset regardless of what its numbers turned out to show. Nothing was dropped for looking good or bad.

Proving a board is official

Feedback subdomains can be registered by anyone, so a hosted board only entered the dataset with a recorded official_ref: a URL on the company's own domain that links or redirects to the board, or a custom subdomain (like feedback.clickup.com) that serves the same board payload, which proves the company controls the DNS pointing at it. Each row in the dataset records which proof applied. GitHub repos are the projects' official repos, and self-hosted boards are official by construction.

Dropped boards

45 of the 74 candidates were dropped: 20 hosted boards no longer expose any public board without logging in, 15 could not be proven official (including one confirmed squatted subdomain), 5 only load posts client-side or via endpoints their robots.txt disallows, 2 had unusable vote data, 2 were excluded before collection, and 1 was excluded on crawl-politeness grounds because its robots.txt disallows the API we would have needed. Every dropped board and its reason is in the dropped array of the raw dataset.

Status normalization

Vendors use dozens of status labels, so we mapped every raw status we saw into three buckets. We were deliberately generous to the boards: "beta" counts as delivered, and anything the vendor plausibly closed as done counts as delivered. Canny's bare "closed" counts as declined, not delivered. For GitHub, closed issues would split by close reason (completed = delivered, not planned = declined), but this snapshot contains open GitHub issues only (see collection budget below), so that split did not apply to any row.

How the numbers were computed

• Snapshot date: all data collected on 2026-07-20 (UTC). Ages are floor((collected_at - created) / 86,400s), all in UTC. Creation dates for Canny posts come from the timestamp embedded in each post's database ID, which records the exact insertion time and is not editable by board admins.
• The top lists we pulled are not filtered to open posts. We checked empirically: delivered and declined posts do appear in them (ClickUp's #1 is a delivered beta), so the "#1 request" metric really is the #1 across all statuses.
• The 1-year and 2-year figures use as denominator only the boards whose #1 request is at least that old: 28 and 27 boards respectively.
• The median-age metric uses each board's 10 most-voted open-not-delivered posts; boards with fewer than 5 qualifying posts would be excluded from that aggregate (all 29 qualified) but stay in the dataset. The threshold is documented in the dataset.
• Hosted boards report votes; GitHub reports thumbs-up reactions. The two units are different things and are never added together anywhere in this post.

Crawl politeness

Collection was serial with at least 2.5 seconds between requests to the same host, using an identified user agent that links to this post and includes a contact email. We made roughly 456 HTTP requests in total, of which 334 were verification fetches of company websites and only 122 were data collection, including per-host robots.txt checks. GitHub data came from the documented public search API within its unauthenticated rate limits (8 calls, open issues only, which is why GitHub boards contribute open-request metrics only). We respected robots.txt everywhere, and boards we could only have read through disallowed endpoints were dropped instead.

The raw dataset, including every post, every dropped board, the full status map, and this methodology in machine-readable form, is downloadable at /data/board-audit.json.

Honest limitations

• This is not a random sample. 29 is the count of boards that survived verification out of 74 candidates, and the sample skews toward companies that run public hosted boards and large open source projects on GitHub. Companies that keep feedback private, or that closed their public boards, are invisible to this method.
• Statuses are self-reported by vendors.A request marked "open" could conceivably have shipped without the board being updated. That cuts both ways: a board nobody updates is part of the graveyard pattern, not an excuse for it.
• Votes and reactions are not the same unit. Board votes involve deliberately visiting a feedback portal; GitHub reactions are one click on an issue. We report them separately everywhere and you should read them separately too.
• A snapshot, not a longitudinal study.All numbers are as of July 20, 2026. Boards change; some of these requests will ship. The linked sources let you check any row's current state.

What FeatQ does differently

We ran this audit because we think the problem is structural. A feedback board that ends at the vote will always drift toward the graveyard, because moving a request from "most voted" to "shipped" requires a human to hand-carry it into the codebase, and that hand-off is exactly what never happens.

FeatQ's answer is to connect the vote to the code. Every board ships with an MCP server that coding agents like Claude Code and Cursor read directly: the agent pulls the top-voted request, turns it into a spec, ships it, and the changelog closes the loop with the people who voted. We wrote up the principle behind this in our no-graveyards manifesto.

We are not claiming immunity. Our own board is public and will age in public. But a board whose top request feeds an agent that writes code has a fundamentally shorter path from vote to shipped than a board whose top request feeds a quarterly meeting.