Three files, printed in full, free to take. No form in front of any of them.
The Markdown one
Pastes into a document, a wiki, a support ticket or an issue body.
# Feature request
## Title
Search the board by the words in the title, not by the feature name
## What problem are you trying to solve?
I have to scroll the whole list to find out whether somebody already asked
for something, so I file a duplicate about once a month.
## What would you like to happen?
A search box above the list that matches the words in a request title.
## What are you doing instead today?
I use the browser's find on page, which only searches the requests already
loaded.
## How much is this holding you up?
Nice to have / Annoying, I work around it / Blocking something I need to do
## Anything else
Screenshots, links to related requests, the number of people on your side.
Take the file. Markdown, free to copy, change and use commercially, no attribution and no link back.
The form for your own site
Four fields, plain HTML, no framework. Point the action at whatever receives your form.
<!--
Feature request form, four fields.
Point the action at whatever receives the submission. Nothing else here needs changing to work.
The labels are questions rather than nouns on purpose, and the placeholder on the second field is a whole worked answer rather than a hint, because showing somebody the shape of a good answer is the cheapest quality control there is.
Free to copy, change and use commercially, with no attribution and no link back.
-->
<form method="post" action="/feature-request">
<label for="fr-title">What is the one thing you want changed</label>
<input id="fr-title" name="title" type="text" maxlength="200" required
placeholder="Searching the board for a request that already exists">
<label for="fr-detail">What is difficult, when does it happen, and what do you do instead today</label>
<textarea id="fr-detail" name="detail" rows="6" maxlength="2000" required
placeholder="Finding out whether something has already been asked for means scrolling the whole list. It happens every time we prepare a release, so today we export to a spreadsheet and search there, which takes about twenty minutes a week."></textarea>
<fieldset>
<legend>How much is this holding you up</legend>
<label><input type="radio" name="severity" value="nice" required>
Nice to have</label>
<label><input type="radio" name="severity" value="workaround">
Annoying, I work around it</label>
<label><input type="radio" name="severity" value="blocking">
Blocking something I need to do</label>
</fieldset>
<label for="fr-email">Email, only if you want an answer</label>
<input id="fr-email" name="email" type="email" autocomplete="email"
placeholder="Optional">
<p>
A person reads every one of these. Nothing you write appears publicly until it has been read.
</p>
<button type="submit">Send</button>
</form>
Take the file instead of the paste. The same four fields, free to copy, change and use commercially, no attribution and no link back.
Nine dollars a month for one project, with weighted voting on it.
The GitHub issue form
Drop this at .github/ISSUE_TEMPLATE/feature-request.yml and the fields render as boxes and dropdowns when somebody opens a new issue. Of the 935 most starred repositories with issues switched on, 484 offer a feature request template and 305 write it as a form like this one.
name: Feature request
description: Suggest something this project should do that it does not do yet.
title: "[Feature]: "
labels: ["enhancement"]
body:
- type: markdown
attributes:
value: |
Please search the existing issues first. If somebody has already asked
for this, add a reaction or a comment there instead.
- type: textarea
id: problem
attributes:
label: What problem are you trying to solve?
description: The situation you are in, not the feature you have in mind.
placeholder: I have to scroll the whole list to find out whether somebody already asked.
validations:
required: true
- type: textarea
id: proposal
attributes:
label: What would you like to happen?
description: Your idea for a solution. Rough is fine.
validations:
required: false
- type: textarea
id: workaround
attributes:
label: What are you doing instead today?
description: The workaround, and what it costs you.
validations:
required: false
- type: dropdown
id: severity
attributes:
label: How much is this holding you up?
options:
- Nice to have
- Annoying, I work around it
- Blocking something I need to do
default: 0
validations:
required: true
- type: input
id: version
attributes:
label: Version
description: Which version or build are you on?
validations:
required: false
- type: checkboxes
id: searched
attributes:
label: Before submitting
options:
- label: I have searched the existing issues for this request
required: true
Is there a Word version of this feature request form template?
Yes. Take the docx.
It is the same six fields with the guidance for each one set in grey above the box, an example answer in the box itself, and a last page of notes for whoever owns the form that tells you to delete it before you publish.
Use it when the form has to be reviewed by somebody who does not open a text editor, or when the request arrives as an attachment rather than through a page. The Markdown version above is the one to keep in the repository.
Is there an Excel version for tracking the requests?
Yes, and it is a different file doing a different job. Take the xlsx.
The form collects one request. The log holds all of them, with eleven columns: the six fields from the form, plus who asked, how many people are on it, the status, a rough effort and the decision with a reason beside it.
Six example rows are already in it, including one marked refused with the reason written out, because the refused rows are the ones that stop the same request arriving every quarter. The header is frozen and every column has a filter on it.
It opens in Excel, in Numbers and in LibreOffice. For Google Sheets, open Sheets, choose File and then Import, and upload it.
Every file on this page is free to copy, change and use commercially, with no attribution and no link back.
What does a software feature request template need that a generic one does not?
Two columns, and both of them are about what happens after somebody presses send.
The first is the workaround. A software feature request without a workaround field collects wishes, and a wish cannot be sized. What somebody is doing instead today tells you what the problem costs them per week, which is the only honest input to whether it is worth a sprint.
The second is the decision with a reason. Software requests do not go away when you ignore them, they come back with the same wording from a different person. A row that says refused and why is the only version of no that holds.
Everything else on a software feature request template is a field somebody added in a meeting.
What belongs on a feature request form?
Four questions, and the first one is the one most forms skip.
The problem, before the solution. A form that only asks what you want gets a list of features and no way to tell which ones matter. Asking what the person is trying to do gets you a problem you can solve three ways, and often the cheapest one was not what they asked for.
What they do instead today. The workaround tells you how much pain there is. Somebody exporting to a spreadsheet once a quarter is not blocked. Somebody doing it every morning is.
How much it holds them up. Three options, not a 1 to 10 scale. Nice to have, annoying, blocking.
Anything else. Screenshots, links, the number of people on their side.
How many fields is too many?
More than five, on a public form.
Every field costs you submissions, and the ones you lose are from the people who were only mildly annoyed, which is exactly the signal you were trying to collect.
The GitHub form asks more because the person filling it in already has an account, already writes issues, and is not going to be scared off by a dropdown.
If you need something a field would have told you, ask for it in a reply after the request exists. A conversation on a request that is already filed costs nothing. A question on a form that has not been submitted costs you the whole request.
Where should the form live?
Wherever the person is when they get annoyed.
A form on a contact page collects requests from people who went looking for it, which is a small and unrepresentative group. A form inside the product, at the moment something did not work, collects them from everybody else.
That is the argument for a board rather than a file: not that boards are better documents, but that the other people who wanted the same thing can see it and add to it instead of filing it again.