Can't use "Issue Type" in issue templates, as recently released

[jkollberg]

Select Topic Area

Bug

Feature Area

Issues

Body

A recent release stating that "You can now add issue types to your forms and templates!" when creating an issue from within a Project (see screenshot), but when configuring a template, that option doesn't exist.

I was really looking forward to this feature, so I would appreciate this being resolved!

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[lemisky]

Feature Request: Add a dedicated "type" field in issue templates

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms

name: 🐞 Bug Report
description: Report a problem to help us improve
title: "[Bug]: "
labels: [ "bug" ]  # not this
types: [ "bug" ]  # this
assignees: [ ]

[mootari]

It's type: "bug" (singular).

Edit: Also, issue types are currently not available for personal repos: https://github.com/orgs/community/discussions/148715#discussioncomment-12179361

[lemisky]

Shocked! Tested and it works, thank you 😘

[girishlade111]

Where the Setting Should Be
The ability to add issue types isn't configured within the Project view itself, but rather in the repository's settings. The "Edit templates" link in your screenshot should take you there.

Here's the manual path to confirm you're in the right place:

Go to the main page of the repository linked to your project.

Click on the "Settings" tab.

In the "General" section of the settings, scroll down to the "Features" area.

Find the "Issues" feature, and click the "Set up templates" button.

Inside this view, when you edit an existing issue form or create a new one, you should now see a new option to assign an icon and a name for the issue type, which is what the new feature is all about.

Why Isn't It Showing Up?

If you've gone to the correct settings page and still don't see the option, there are a couple of likely reasons:

Phased Rollout (Most Likely): This is the most common reason. GitHub often rolls out new features progressively. Your organization or repository might simply not be in the batch that has received the feature yet, even though the announcement banner is visible. It can sometimes take a few days to a week for a feature to be available to everyone.

A Minor UI Bug: It's possible that the announcement banner was enabled for you, but the feature flag for the actual settings page wasn't. This would be a bug.

Permissions: To edit issue templates, you need to have write or admin permissions for the repository. It's worth double-checking that you have the correct access level.

What to Do Now

Hard Refresh: The simplest first step is to do a hard refresh (Ctrl+Shift+R or Cmd+Shift+R) on the issue template settings page to make sure you're not seeing a cached version of the page.

Wait a Day or Two: If it's a phased rollout, the feature may just appear on its own soon.

Report to Support: If you've waited and are sure you have the right permissions, the best course of action is to report this directly to GitHub Support. They can look at your specific repository and see if it's a bug or if the feature flag hasn't been enabled for your account yet.

[girishlade111]

You've run into a common point of confusion when migrating from markdown templates to the more structured issue forms. You are correct: the type metadata key is not a valid field in the issue form YAML schema.

However, you can achieve exactly what you want (and in a more powerful way) by using a dropdown selector in the form itself, which then automatically applies the correct label.

The Modern Approach: Using a Dropdown for Issue Type

Instead of a hidden metadata field, the best practice is to ask the user to select the issue type from a list. This makes the classification clear to the person reporting the issue and ensures the right label is always applied.

Here is how you can modify your bug.yml issue form template to include this:

name: 🐞 Bug Report
description: Report a problem to help us improve
title: "[Bug]: "

labels: [ "bug" ]
assignees: []
body:

• type: markdown
  attributes:
  value: |
  Thanks for taking the time to fill out this bug report!

• type: dropdown
  id: issue-type
  attributes:
  label: Type of Issue
  description: What classification best fits this issue?
  options:
  - Bug
  - Performance Issue
  - Security Vulnerability
  validations:
  required: true

• type: textarea
  id: what-happened
  attributes:
  label: What happened?
  description: Also tell us, what did you expect to happen?
  placeholder: Tell us what you see!
  validations:
  required: true

How This Solves Your Problem

Enforced Selection: By adding validations: { required: true } to the dropdown, you force the user to categorize their issue before they can submit the form.

Automatic Labeling: While the dropdown itself doesn't add a label, you've already defined labels: [ "bug" ] at the top of your form. This is the correct way to ensure every issue submitted through this template gets the "bug" label.

Filtering and Management: You can now easily filter for the "bug" label on your issues board, which perfectly satisfies your need to manage issues by type.

So, while the old type key is gone, the combination of a top-level labels key and an optional dropdown input in the form body gives you a much more robust and user-friendly way to achieve the same goal. Hope this helps! 😘

[lemisky]

Thank you for your reply. While labels can indeed be used to manage issues, we have been using issue types to manage issues for a long time, including in Milestones & Projects, and we don’t want to make major changes for now.

Is using labels considered the more modern recommended approach?

[girishlade111]

Yes, absolutely. Using labels is now the modern and officially recommended approach for managing and categorizing issues within GitHub's ecosystem.

I understand your hesitation completely. When you have a workflow that your team has been using for a long time in Projects and Milestones, making a change feels like a major disruption.

Why Labels Are the Recommended Approach

The main reason for this shift is that labels are a "first-class citizen" throughout the entire GitHub platform. The old type field in markdown templates was just a simple piece of metadata; it didn't actually do anything in the GitHub UI.

Labels, on the other hand, are deeply integrated into every tool:

Filtering: The primary way to filter, search, and create views in Issues, Projects, and Milestones is based on labels.

Visuals: They are color-coded and clearly visible at a glance, making it easy to quickly assess the state of a list of issues.

Automation: GitHub Actions and other automation tools are designed to work directly with labels. You can build workflows that automatically assign team members, add issues to a project board, or leave comments based on the labels applied.

Because of this deep integration, GitHub has standardized on labels as the primary method for all forms of issue classification.

A Recommendation for Your Transition

You don't have to completely overhaul your mental model overnight. You can make a small change that adopts the modern system while keeping your existing terminology.

Consider creating labels that mirror your old types. For example, you can create labels like:

Type: Bug

Type: Feature Request

Type: Question

Then, in your new issue form, you can have the dropdown apply the corresponding label. This way, your team can still filter for "Type: Bug" in your Projects and Milestones, just as they did before. You get the benefit of the new, more robust issue forms while causing minimal disruption to your team's established management process.

It’s a small change in implementation, but it aligns your project with the powerful, integrated features that GitHub is building around labels.

[lemisky]

@girishlade111 You are so bad — you're actually a robot, I'm furious. 🙄

[farshidtz]

This is now supported, try:

type: Bug

[Chiragj2003]

Hi everyone 👋

It looks like there’s been some confusion around the new “issue types” feature and how it integrates with issue forms and templates. Here’s a quick summary to help clarify things:

1. Where to Find the Setting
   The “Issue Type” configuration isn’t managed directly inside the Project view. You’ll need to go into your repository’s Settings → Features → Issues → Set up templates. When editing or creating a form-based issue template, you should now see the option to assign a type (e.g., Bug, Task, Feature).

2. Why You Might Not See It Yet
   This feature is being rolled out gradually. Some accounts or organizations might see the announcement banner before the functionality is fully enabled. If that’s the case for you, it should become available soon.

3. Recommended Modern Approach
   If you’re still waiting for access, you can achieve similar results using labels or dropdown fields in your issue forms. For example:

type: dropdown
id: issue-type
attributes:
label: Type of Issue
options:
- Bug
- Feature Request
- Question
validations:
required: true

You can pair this with the appropriate label to maintain your existing workflows until native issue types are fully supported.

4. If You Suspect a Bug
   If you’ve confirmed you’re on the latest version and the feature still doesn’t appear, it could be a UI or rollout flag issue. In that case, I recommend reaching out directly to GitHub Support
   with your repository link and screenshots.

Hope this clears things up a bit! The new issue types system is a great addition once it’s fully enabled, and labels or dropdowns are solid workarounds in the meantime. 🚀