Why ask for a problem statement first?

Leading with the problem keeps requests grounded in a real need rather than a pre-baked solution. It helps maintainers evaluate whether the underlying pain is worth solving, even if the proposed approach changes.

Where do I put this file?

Save it as .github/ISSUE_TEMPLATE/feature_request.yml. GitHub scans that directory and lists every template when a contributor opens a new issue.

What labels should I default to?

enhancement is the GitHub convention for feature requests, often paired with a triage label so the team knows it still needs review. The tool lets you set any comma-separated list.

How is this different from the bug template?

A bug template captures what is broken and how to reproduce it. A feature template captures a desired capability, the problem behind it, and trade-offs against alternatives, so the fields and prompts are entirely different.

Can contributors skip the form?

If you add a config.yml with blank_issues_enabled set to false, GitHub forces every new issue through one of your templates, which keeps feature requests consistently structured.

GitHub Feature Request Issue Template Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

A good feature request explains the problem before the solution. This builder generates a feature_request.yml issue form that guides contributors through a Problem Statement, a Proposed Solution, the Alternatives they considered, and any Additional Context — so your backlog stays evaluable.

How it works

The output is a YAML issue form: top-level metadata (name, title, labels, assignees) plus a body of typed fields. Free-form sections use textarea fields, and required ones set validations.required: true:

- type: textarea
  id: problem
  attributes:
    label: Problem Statement
    placeholder: I'm always frustrated when ...
  validations:
    required: true

GitHub detects the file under .github/ISSUE_TEMPLATE/ and shows it as a choice on the New Issue screen, automatically attaching your default labels (commonly enhancement) and any assignees to each submission.

Tips and notes

Make the Problem Statement required and the rest optional — that single constraint stops “build me X” tickets with no rationale. Keep the title prefix (for example [Feature]: ) so feature work is easy to filter. Pair this template with the bug template and a config.yml that disables blank issues to route all feedback through structured forms.