← Feedback board

Feature request template, in Markdown, HTML and as a GitHub form

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>

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.

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

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.

Related reading

Release notes template, free, in Markdown and plain text Bug vs feature request, and the one question that decides A suggestion form nobody needs an account for