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.

What is the GitHub Feature Request Issue Template Builder?

Builds a GitHub feature request issue form (feature_request.yml) with Problem Statement, Proposed Solution, Alternatives Considered, and Additional Context fields using the YAML issue-form schema, ready for .github/ISSUE_TEMPLATE. It runs free in your browser on Gera Tools, with nothing uploaded.

GitHub Feature Request Issue Template Builder

Name: GitHub Feature Request Issue Template Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

Why structure a feature request differently from a bug report

A bug report needs reproduction steps and expected vs. actual behavior. A feature request needs a completely different shape. Without structure, feature issues tend to be one-liners like “please add dark mode” — impossible to prioritize because the underlying problem, scope, and alternatives are unknown.

The four-section format this template generates solves that:

Problem Statement — anchors the request in a real user pain. “I always have to export to CSV and re-import to update records” is actionable; “make it faster” is not.
Proposed Solution — lets the requester share their mental model of the fix without locking the team into it.
Alternatives Considered — surfaces workarounds the user already tried, which tells you whether they will accept a lighter solution.
Additional Context — a catch-all for screenshots, links, and related issues that help without cluttering the required fields.

What a complete generated file looks like

After configuring the form, the tool produces something like:

name: Feature Request
description: Suggest a new feature or improvement
title: "[Feature]: "
labels: ["enhancement", "triage"]
assignees: []
body:
  - type: textarea
    id: problem
    attributes:
      label: Problem Statement
      description: What problem are you trying to solve?
      placeholder: I'm always frustrated when ...
    validations:
      required: true
  - type: textarea
    id: solution
    attributes:
      label: Proposed Solution
      description: What would you like to see?
    validations:
      required: false
  - type: textarea
    id: alternatives
    attributes:
      label: Alternatives Considered
      description: What other approaches have you considered?
    validations:
      required: false
  - type: textarea
    id: context
    attributes:
      label: Additional Context
      description: Screenshots, links, related issues
    validations:
      required: false

Save this as .github/ISSUE_TEMPLATE/feature_request.yml (note the .yml extension — GitHub also accepts .yaml). Commit and push; GitHub picks it up immediately without any other configuration.

Practical tips for teams

Make the Problem Statement the only required field. That single constraint filters out low-effort submissions while still allowing partial requests through. Everything else can be filled in during triage.
Use a title prefix like [Feature]: . It makes filtering by type trivial in searches and in project boards.
Add a config.yml alongside your templates to disable blank issues (blank_issues_enabled: false). This routes every new issue through a template and prevents the “just opened a blank issue” pattern.
Assign a triage label automatically. The labels field in the template lets you tag submissions without requiring contributors to know which labels exist.
Pair with the bug template. Together they cover the two most common issue types. GitHub presents both as choices, so contributors self-select the right form.