Feature Requests: Template, Real Examples, and Replies
Shayan, Founder17 min read
What is a feature request? A user asking for a capability the product lacks, with the reason they need it. The reason is the useful part. A request filed on Cal.com's tracker in October 2026 asks for a "spam" booking status, and the first line under it is the problem: "The API reports only accepted, pending, rejected, cancelled and awaiting_host. Unconfirmed bookings can't be rejected once their time has passed, so bot bookings stay "pending" in reporting forever." The title says what to build. The problem line is what the team needs when it cannot build it that way.
Twelve well-known open-source projects publish a form for feature requests, and the fields agree more than the articles that rank for the phrase do: 11 of the 12 ask what you propose, 9 ask what problem it solves, and 6 ask what you tried instead. The rest of this guide is built from those forms, from the public boards and issue trackers of 24 products, and from 58 threads of replies by staff, maintainers, and their bots: a template, a GitHub issue form, how teams decide, what to write back, and what to send when the feature ships.
What is a feature request?
A feature request is a request from a user for a capability the product does not have. It can arrive as a support conversation, a forum post, a GitHub issue, a vote on a board, a sentence in a sales call, or a tweet. It is distinct from a bug report, which says the product fails to do something it already promises. Kubernetes calls its form an "Enhancement Tracking Issue", and PostHog labels requests both enhancement and feature; the two words name the same thing.
The projects that take requests seriously define them by the problem, not the wish. Node.js's form asks three questions: "What is the problem this feature will solve?", "What is the feature you are proposing to solve the problem?", and "What alternatives have you considered?" Obsidian's forum template opens with "What's your use case for this feature? In other words, what are you trying to accomplish when you realize you need this feature?" Grafana's contributor guide gives a weak example, "Dashboard export doesn't work well with variables.", and tells writers to avoid "Jumping directly to the solution" and "Vague statements like "it would be nice if..."".
Feature request or bug report?
A bug is the product breaking a promise; a feature request asks for a new one. The line matters because most teams route the two differently. Expo's GitHub form for feature requests exists only to turn people away: it has one required dropdown, "Do you understand that any feature requests opened in the core Expo repository will be closed?", with the single option "Yes", and sends them to its Canny board. Home Assistant treats a request to make a third-party integration built-in as already answered when the integration exists: "If a custom integration exists (for example, via HACS), we consider the request resolved".
What a good feature request contains
The forms from VS Code, Next.js, Node, Obsidian, Grafana, Home Assistant, Flutter, Kubernetes, Ruff, Cal.com, PostHog, and Expo ask for these, in order of how many ask:
- The proposed solution. 11 of 12. Flutter's wording: "Briefly but precisely describe what you would like Flutter to be able to do. Consider attaching something showing what you are imagining: images, videos, code samples".
- The problem or use case. 9 of 12. Grafana's: "Add a description of the problem the feature is trying to solve." Home Assistant calls the field "Current limitations".
- Alternatives tried. 6 of 12. Obsidian asks for the "Current workaround (optional)"; Flutter asks "Is there a package on pub.dev/flutter that already solves this?"
- A search for duplicates first. 4 of the 12 tell you to search before you post. VS Code: "Please search existing issues to avoid creating duplicates." Obsidian: "If your request is very similar to an existing one, like it (❤️) and make a meaningful comment, rather than creating a new thread."
- Who it is for. Grafana alone asks "Who is this feature for?", and Next.js alone asks for "Goals" and "Non-Goals".
The field almost every published template leaves out is a way to reach the person. Of 58 templates on the pages that rank for feature request searches, 6 ask for an email or other contact. The rest collect a request from someone who can never be told what happened to it.
Feature request template
The template below is what the twelve forms agree on, plus Grafana's question about who it is for and a contact line. Copy it into a board, a form, or an email autoreply.
# Title: one line, what the user could do afterwards
## Problem
What are you trying to do, and what stops you today? Describe the
situation, not the feature.
## Proposed solution
What would you like the product to do? A screenshot, sketch, or
example from another tool helps.
## What you do instead today
The workaround, if there is one, and what it costs you.
## Who this is for
Just you, your team, or your customers.
## How to reach you
Email or account, so we can ask a question and tell you when it ships.A GitHub issue form for feature requests
GitHub issue forms are YAML files in .github/ISSUE_TEMPLATE/, and unlike Markdown templates they can make a field required. This one mirrors Node's three questions and adds the duplicate check.
name: Feature request
description: Suggest something the project does not do yet
labels: ['feature request']
body:
- type: checkboxes
attributes:
label: Before you post
options:
- label: I searched existing issues and discussions for this request
required: true
- type: textarea
id: problem
attributes:
label: What is the problem this feature will solve?
validations:
required: true
- type: textarea
id: proposal
attributes:
label: What is the feature you are proposing to solve the problem?
validations:
required: true
- type: textarea
id: alternatives
attributes:
label: What alternatives have you considered?Feature request document
A feature request document is the one-page write-up a team makes once a request has enough weight behind it to be decided properly. It carries the problem in the requesters' words, the evidence, the proposal, what is out of scope, the open questions, and the decision with its date. Rust's RFC template is the heavyweight version, with sections for Motivation, Drawbacks, "Rationale and alternatives", "Prior art", and "Unresolved questions"; Kubernetes's KEP adds a test plan and graduation criteria. For a SaaS team, one page is enough, and the request on the board is where it links from.
# Feature request: <name>
## Problem
In the requesters' words. Link the requests on the board.
## Evidence
How many asked, how many voted, which customers, which conversations.
## Proposal
What we would build, in a paragraph.
## Out of scope
What this does not cover, so the request does not grow in review.
## Open questions
## Decision
Build, later, or no, with the reason and the date.Where feature requests come from, and where to keep them
Of 24 well-known products checked on October 31, 2026, 12 have a public place to post a request where others can react or vote. Obsidian and Ghost run Discourse forums; 1Password and Miro run Gainsight communities, and Figma's Gainsight forum has likes but no votes ("At the moment, it is not possible to vote on topics."); Plausible is on Nolt; Webflow on Aha! Ideas; Loom and Jira take suggestions on Atlassian's public Jira; Spotify runs its Idea Exchange on Vanilla; Cal.com and PostHog take requests as GitHub issues with reactions. Notion, Raycast, Todoist, Linear, Fathom, and Arc show no board; Raycast takes requests through a feedback command, and Framer's arrive as ordinary community posts. Among open-source projects, Expo and Strapi use Canny, and Home Assistant, Supabase, Tailwind, and Next.js use GitHub Discussions.
Wherever the board lives, requests also arrive elsewhere: in a support chat, a reply to an onboarding email, a sales call, a GitHub issue filed as a bug. The job is to get each one onto the one list, as one post per request, in the requester's words, with the requester attached. Strapi's board rule: "One post = one request. If you have several ideas, please split them into separate posts."
Duplicates are the other half. Prettier's template says "A large number of opened issues are duplicates of existing issues" and asks for a 👍 reaction on the existing one instead. Jira Cloud's tracker has closed 1,893 suggestions as duplicates. A board that shows similar requests as the person types, and lets you merge the ones that slip through without losing the votes, does most of that work before a moderator sees it.
How teams decide what to build
The clearest published process is VS Code's. Its triage wiki walks every feature request through four questions: whether "the proposal match[es] with our general product direction", whether "our team [can] afford to implement the feature", whether it has "any reasonable chance to be implemented in the next 24 months", and whether "the community at large [has] expressed interest in this functionality? I.e. has it gathered more than 20 up-votes." A "no" to the first two closes the issue as out of scope. The rest go to a "Backlog Candidates" milestone, and a bot does the counting:
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it.
Node.js's contributor docs say the reverse: "Feature requests are not a valuable source of input for the project. It is usually more productive to first send the Pull Request implementing the feature, even imperfectly, and let the discussion happen during code review." Its stale bot marks a request after 90 days of silence and closes it 30 days later. Prettier has stopped taking one whole class of request: "Option requests aren't accepted anymore." Obsidian's team says it has "thousands of feature requests, each as valid for at least one user as the last", and takes "a fuzzy approach to prioritizing requested features"; Steph Ango, who helps make Obsidian, wrote on Hacker News in June 2026 that the team is "only seven people" and that when he asked the community what to remove from the app, "I mostly got feature requests". Jeff Geerling, who maintains dozens of small open-source projects, put the maintainer's test in one line in 2016: "will this new code/feature make the project easier or harder to maintain?"
Few teams publish numbers. UserVoice, which sells feedback software, reports 1,724 requests on its own portal with 382 shipped, "a 22.2% delivery rate". Atlassian's public tracker for Jira Cloud held 28,060 suggestions on October 31, 2026; by our count 2,346 were closed as fixed or done, 9,356 as won't fix, and 5,628 were still "Gathering Interest". Some of the most-voted requests have waited longest: Jira's "Default values of system fields" has been open since 2004 with 2,798 votes, Ghost's footnotes request since 2018, and Spotify's top idea, at a score of 26,457, carries no status at all.
Prioritisation frameworks are a separate subject, and two guides on this site cover them: how to prioritize feature requests and how to assess feature requests. Whatever the framework, the requester may not like the outcome, and VS Code's wiki says so: "If you are the author of a feature request you might not like that we close or don't plan to address your request. It might even feel like a slap in your face. We understand that."
How to reply to a feature request
Every request gets one of five answers: we will build it, tell us more, no, this already exists, or it shipped. The first four are below, with real replies from staff and maintainers on public boards. The fifth has its own section.
We will build it. Ghost's John replied to a request for nested tags in April 2018 with seven words, "Nice - we're definitely going to do this!", then in November with "This is now in progress", then in February 2019 with "Sorry, yes - this actually ran into a few technical challenges and got put on pause at the end of last year. Will hopefully be able to circle back to it soon." In 2020 he closed the thread "because "ya cant believe this isnt done yet" isn't useful to anyone." In May 2024, on the footnotes request, Ghost's Kevin wrote: "The footnotes feature request hasn't been forgotten/ignored, it's still planned and we're still working towards it. When there are updates we'll post them here." Obsidian answers in seven words: "Will be implemented in v1.11.x No ETAs."
Tell us more. Ghost's moderator on a request for subscribe forms: "it's not clear to me what you are suggesting as an #ideas. The Ghost Memberships module already provides sign-up forms with a follow-up confirmation email." Ruff's maintainer on a configuration request: "A good start would be a proposal for how the option would work (what is it named, what are the defaults, etc)". A Rust project leader on the internals forum, on a proposed compiler default: "The best way to make a case for it would be to document which debuggers (or other tools relying on debug information) do and don't support it, in which versions, and thus which debuggers/tools we'd be breaking if we did this."
No. The short ones point at a written policy. Prettier, seven words and a link: "Sorry, we can't add option for this. https://prettier.io/docs/option-philosophy". Ghost, two words plus four links to articles on why links should not open in new windows: "Absolutely not." The useful ones give the reason and a route. Node closed "enable corepack by default" in March 2025 with: "Closing this issue as "not planned" as the Node.js TSC voted to stop distributing corepack in Node.js v25+ Corepack is not going away, and it will still be available on npm. You can still continue to use corepack by replacing the command corepack enable to npm i -g corepack. If you're a corepack user and want to contribute to its development, please refer https://github.com/nodejs/corepack/issues/681". Kubernetes declined deny rules for RBAC in 206 words that name the reason ("complexity, implications to upgrades, and unclear superuser/non-superuser interactions") and the door that stays open: "a proposal that works through the design along with the implications of such a change can be opened as a KEP and brought to sig-auth formally for review." Atlassian's product manager, moving a 17-year-old request with 594 votes to "Not being considered" in May 2023: "There are still no plans to implement this suggestion at this stage. We know that transparency is important for you to plan how to best work with Jira, and will be transitioning this issue to "Not being considered". We understand our decision may be disappointing."
A no is not always the end. VS Code closed "File Nesting" in July 2016 with "No plans at the moment. Closing until we reconsider this.", reopened it three months later, and shipped it in January 2022 with 670 upvotes behind it. Flutter closed a drag-and-drop request with 270 upvotes by recommending a third-party package instead of building one.
This already exists. Flutter's reply to a duplicate, the day it was opened: "Thanks for the detailed use case. This is tracked in #188776. The Impeller side landed in #188778, and the Flutter GPU API landed on master in #190036". It names where the work is, what has landed, and which release it reaches. Prettier's version is three words, "Duplicate of #13500", which is enough when the link does the rest.
Then there is no reply at all. Obsidian's team says plainly that "the team does not respond to feature request, know that every one is read and considered". Apple's consumer feedback form has a "Feature Request" type and says "We read all feedback carefully, but we are unable to respond to each submission individually." Grafana let a Google Analytics request with 117 upvotes sit from 2016 until a bot closed it in 2024 "because it has not had any further activity in the last 30 days." A bot can carry the routine replies, as VS Code's does for its vote window; a bot closing a seven-year-old thread for inactivity is a different message, and the people in the thread read it as one.
Across the 58 threads, the replies that read well years later do four things: say which of the five answers this is, give the reason in a sentence, say what happens next, and name the place to continue if there is one.
Telling people when it ships
Of the fifteen pages that reach the top three for six feature request searches, eight say to notify the requester when the feature ships, and none of the 42 ranking pages shows a message a real team sent. These are real.
Spotify's staff, on an idea with a score of 91, in June 2026: "Hey folks, Thanks for coming to the Spotify Idea Exchange and voting to make this happen. We're happy to announce that transitions on Mixed playlists are now available on desktop as well." A Home Assistant maintainer, on a request from a year earlier: "This has been implemented in home-assistant/core#161547 and shipped with Home Assistant 2026.2. The MCP integration now connects using Streamable HTTP first and falls back to SSE when needed." Ghost's staff, on a request from 2021: "Gift subscriptions are now an official feature in Ghost", followed by the changelog card. Atlassian, in July 2026, on a request from 2015 with 542 votes: "Formula Fields are now Generally Available in Jira Cloud! This has been one of the most requested features in Jira's history, and it's finally here. Thank you for your patience, your votes, and the feedback".
They name the request, and most name the release, so the person who asked knows it is theirs. They also arrived late: Home Assistant's came about eight months after the release it cites, in a sweep that closed at least five shipped requests on one day, and Ghost confirmed a release seven weeks after a user asked whether it had happened.
The message that closes the loop needs the request's name, what shipped, where to find it, and a link to the release notes or changelog entry. It needs to reach everyone who voted and commented, which is the list a board keeps and an inbox does not.
Every status change emails everyone who asked.
On a UserJot board, every status change emails everyone who posted, voted, or commented on the request, and your changelog post links back to it. Free to start.
From the conversation to the shipped request
On UserJot, a request made in the chat widget and a request posted on the board end up in the same place. When a customer describes a feature in chat, Juno, the support agent, searches the public feedback board, shows them the matching request, and once they confirm, adds their vote or files the request. Requests posted on the board or in the widget show similar requests as the person types. Your team works from one list, with every request's votes, status, and the people who asked.
Statuses are six and fixed: Pending, Reviewing, Planned, In Progress, Completed, Closed. Planned and In Progress put the request on the public roadmap, and Completed moves it to the Done column. Every status change emails everyone who posted, voted, or commented. Merging a duplicate moves its comments across and counts each voter once. In the changelog editor, Juno drafts the post from the requests you completed since the last one and links them, so each one shows under the post.
How to handle feature requests
The sections above hold the detail; this is the process they add up to, for a small SaaS team:
- One list. Every request ends up on one board, one post per request, in the requester's words, whatever channel it came in on. The support inbox, GitHub, and sales calls feed it.
- The problem on every post. If a request arrives as a solution, ask for the problem before you file it, in Node's words: "What is the problem this feature will solve?"
- Duplicates merged, votes kept. Show similar requests before someone posts. Merge the ones that get through and keep the votes.
- A decision rule you publish. VS Code's is 20 upvotes in 60 days and a 24-month horizon. Yours can be simpler, but it should be written down where requesters can read it.
- One of five replies, with a reason. Build it, tell us more, no, already exists, shipped. Say which, say why, say what happens next.
- A status on every open request. Planned, In Progress, and Completed are the three a requester cares about. Nothing should sit open and silent for a year.
- The shipped message names the request. It goes to everyone who voted, with the release and a link to what changed.
Frequently asked questions
What is a feature request?
A user asking for a capability the product lacks, with the reason behind it. The best forms ask for the problem first, then the proposed solution, then what the person does instead today.
What is the difference between a feature request and a bug report?
A bug report says something the product already offers is broken. A feature request asks for something it has never offered. Teams route them differently: Expo closes feature requests filed as GitHub issues and sends them to its board, and Home Assistant treats a request to make a third-party integration built-in as resolved when a custom integration already exists.
What should a feature request include?
The problem, the proposed solution, the workaround used today, who it affects, and a way to reach the requester. The proposed solution and the problem are the two fields nearly every open-source form requires; alternatives tried is the third most common.
How do you write a feature request?
Start with what you are trying to do and what stops you, not with the feature. Grafana's guide gives "Dashboard export doesn't work well with variables." as the weak example and tells writers to avoid "it would be nice if". Search for an existing request first and vote on it rather than posting a second one. Attach a screenshot or a sketch if the solution is visual.
What is a feature request document?
A one-page write-up for a request that is being decided: the problem in the requesters' words, the evidence, the proposal, what is out of scope, open questions, and the decision with its date. The skeleton is in the template section above. It is the light version of an RFC or a Kubernetes enhancement proposal, and it links from the request on the board.
How do you say no to a feature request?
In one sentence that gives the reason, with the door left open where one exists. Node's corepack reply gives the vote that decided it and the command to use instead. Atlassian's "Not being considered" reply names the status the request is moving to. Both say what happens next, and neither leaves the requester guessing whether anyone read it.
How many feature requests get built?
Fewer than requesters expect. UserVoice reports 382 of 1,724 requests shipped on its own portal, 22.2%. On Jira Cloud's public tracker, of 28,060 suggestions, 2,346 were closed as fixed or done and 9,356 as won't fix, by our count on October 31, 2026. No other company appears to publish a figure.
How long do feature requests wait?
VS Code decides within 60 days of a request becoming a candidate and only backlogs what it can imagine shipping in 24 months. At the other end, Jira's formula fields shipped eleven years after the request, VS Code's file nesting five and a half years after its first "No plans", and Ghost's footnotes request has been planned since 2018.
Should you reply to every feature request?
VS Code's bot sends the routine replies, so every candidate hears the rule and the deadline. Obsidian's team does not reply and says it reads every one. Apple says it cannot respond individually. A status that changes, with an email when it does, reaches more people than a hand-written reply on each thread, and it never leaves a thread to be closed by a bot years later.
What is an enhancement request?
Another name for a feature request. Kubernetes calls its form an "Enhancement Tracking Issue", GitHub's default labels use "enhancement", and PostHog applies both enhancement and feature to the same kind of issue.
