Feature request board
A request board that moves when the work does.
People outside your team post requests and vote. You triage them and link each one to a task. The roadmap follows that task, and when you publish the change, everyone following the request gets an email.
Free during the preview. No card.
How a request travels
Five steps, one system. Nothing is copied between tools by hand.
Someone asks
Anyone can read the board without an account. Posting, voting, following and commenting need a sign-in, which does not have to belong to your workspace. While they type, the form suggests requests that look like the same thing.
You triage
New requests wait under Needs review. Accept one and it goes on the board with a number. Decline it quietly, block the person if needed, hide it, or merge it into an existing request, which moves its votes and followers across. A board can also publish new requests at once, marked under review.
Others vote and follow
Posting or voting follows the request automatically, and anyone can unfollow. Voting closes when a request is shipped, declined as won't do, or merged.
The roadmap follows the task
Promote a request to a task, or link it to one you already have. The request shows as planned while the task waits, in progress once it starts, and shipped when it is done. Nobody drags cards on a roadmap.
The changelog answers
Write a changelog entry, link the requests it covers and publish it. Everyone following those requests gets one email, with a one-click unsubscribe for that board. The changelog also has its own page and an RSS feed.
What you decide
- Whether the board exists
- Each project's board is off until an admin turns it on. Turning it on publishes nothing: ideas filed inside the app stay private until someone posts one to the board.
- Its address and words
- The board lives at /p/ followed by your workspace and board addresses, with your own title and description.
- Which statuses are public
- Open, under review, planned, in progress, shipped and won't do. Show the ones that help your readers and keep the rest internal.
- Whether search engines index it
- Off by default. Turn it on and the board, its reviewed requests, roadmap and changelog become indexable, while sorted and filtered views, requests under review, and empty lists stay out.
What strangers see, and what they do not
- Your team posts as your workspace's team, never as a named person.
- Nobody's email address is shown on the board.
- Files attached inside the app are never served on a public page.
- A request that is off the board, or a board that is off, answers the same not-found page as one that never existed.
Not built yet
- An embeddable widget or a custom domain for the board.
- Intake forms and a helpdesk inbox.
- Integrations with chat or code hosts.
Further reading
- A changelog RSS feed that works in every reader: a field-by-field checklist
What RSS 2.0 and its best practices profile require of a changelog feed, field by field, and the mistakes that show entries twice or as one run-on paragraph.
- Emailing voters when a feature ships: unsubscribe, link scanners and sending once
Who should get the shipped email, what RFC 8058 one-click unsubscribe requires, why the unsubscribe link must not act on GET, and how to avoid sending twice.
- Should search engines index your feature request board?
A page-by-page indexing policy for public request boards, roadmaps and changelogs, built from Google's documentation, with the defaults that hide or leak pages.
- Comparing progress across projects that name their workflow states differently
Map every workflow state to one of five categories so WIP, throughput and cycle time compare across projects. A worked example, plus the edge cases.