Issue Types Public Preview

[github-staff]

Feedback wanted

Thank you for participating in the issue types public preview. Please leave your feedback below on what is working well, any bugs you encounter, and what else you’d like to see!

To provide your feedback on other experiences released at the same time, please visit:

• Evolving GitHub Issues - Public Preview #148713
• Sub-issues Public Preview #148714
• Advanced Search for Issues Public Preview #148716

Issue types

Issues types allow you to classify and manage your issues with a shared and consistent language across all repositories in the organization, such as bugs or tasks.

Customizing default issue types

An organization administrator can customize the issue types that makes sense for the organization from the organization settings "Planning" page in the “Issue types” section, with bug, task, and feature provided by default to get you started. These are available for all repositories in the organization.

Organization settings page

Adding a type to an issue

When you create a new issue, you can change the issue type using the Type section on the right. You can also change the issue type from this location once an issue has been created.

Screen.Recording.2024-09-30.at.1.45.49.PM.mov

When creating a sub-issue from an issue, you'll find this at the bottom next to the other issue metadata.

Additionally, you can specify the type qualifier in issue forms in your repositories, so that each issue created from each template automatically has the type set. See the documentation here.

Issue form with `type` field

If you’d like to add or change the issue type for existing issues, you can update it from the repository page by selecting one or multiple issues using the checkbox to the left of each issue, or from a project using the Type field by copying and pasting or dragging cells.

Creating custom views in your project

In a project, you can use the new Type field to customize your views by filtering, sorting, slicing, or grouping, so you can visualize and understand the breakdown of your issues.

You can even use the Type field in the auto-add to project workflow, so you can automatically add these to your project.

Auto-add to project workflow

Automating issue types

There are now typed and untyped webhook payload objects for the issues webhook event that trigger a GitHub action.

Issue types are supported in the REST API to manage issue types, adding them to issues, and search within a repository or organization. See the documentation for more details.

For the GraphQL API, there is an IssueType object to manage issue types at the organization level to create, update, and delete them. You can also create a new issue with an issue type, update the issue type, and query a repository by issue type.

Click to view GraphQL details

Note that these requests will need to include the GraphQL-Features header with a value of issue_types.

Objects and Fields

Query Issue.IssueType
Returns issue type based on issue ID

  node(id:ID) {
    ... on Issue {
      issueType {
        id
        name
      }
    }
  }
}

Query IssueType
Returns fields for issue type i.e. private, enabled etc.

  node(id:ID) {
    ... on IssueType {
      id
      name
      isEnabled
      isPrivate
    }
  }
}

Query IssueType.issues connection (w/ repository argument)
Returns total count of issues (with associated fields i.e. title, state etc) with an issue type based on specified repo.

  organization(login: LOGIN) {
   issueTypes(first: 10) {
      nodes {
        id
        name
        # Fetch the first 10 issues with this issue type
        # From the given repository
        # With an open state
        issues(first: 10, repositoryId: REPO_ID, states: OPEN) {
          nodes {
            id
            number
            title
          }
          totalCount
        }
      }
    }
  }
}

Query issueTypes using global search filter API
Org wide searches for issue type.

  search(type: ISSUE, first: 100, query: "type:Bug org:production") {
    issueCount
    nodes {
      ... on Issue {
        title
        repository {
          nameWithOwner
        }
      }
    }
  }
}

Mutations

Create Issue Type

mutation {
  createIssueType(input:{
    ownerId: "ID"
    name: "NAME"
    isEnabled:true
    isPrivate: true
  }) {
    issueType {
      id
    }
  }
}

Update Issue Type

mutation {
  updateIssueType(input:{
    issueTypeId: "ID"
    name: "NEW NAME"
  }) {
    issueType {
      id
    }
  }
}

Delete Issue Type

mutation {
  deleteIssueType(input:{
    issueTypeId: "ID"
  }) {
    deletedIssueTypeId
  }
}

Create Issue -> w/ Issue Type

mutation {
  createIssue(input: {
    repositoryId: "ID"
    title:"test-api-2"
    issueTypeId: "ID"
  }) {
    issue {
      id
      url
    }
  }
}

Update Issue -> w/ Issue Type

mutation {
  updateIssue(input: {
    id: "ID"
    issueTypeId: "ID"
  }) {
    issue {
      id
      url
    }
  }
}

Update Issue Issue Type

mutation {
  updateIssueIssueType(input: {
    issueId: "ID"
    issueTypeId: "ID"
  }) {
    issue {
      id
      url
    }
  }
}

Next steps

We are continuing to improve the Issues experience, and so we’d love to hear your feedback as you try out the new experience and start using issue types.

Closing Discussion Notice

As we've shipped the GA for Issues today, we are closing this discussion. Please direct all Issues and Projects feedback in the Evolving GitHub Issues and Projects (GA) discussion. Thank you!

[hyangah]

Congrats for the feature release.
What are the key differences between the traditional label and this new issue type,
and when do you recommend users favor "issue types" instead of "labels"?

[jahirfiquitiva]

I agree this could've been "solved" by implementing organization-wide labels, instead of creating a new field that is also limited to issues only (not available for PRs) as mentioned by @probitcarwyn.

[probitcarwyn]

Thinking about it a bit more, issue types could have been implemented as namespaced labels where types are a namespace (optional at the discretion of the organisation). You often see namespaces emulated via naming conventions like type:bug or type-bug. Existing labels would then just be in the default namespace, and something tidy could be done to make a given namespace repo or org scoped.

There's another parallel to labels too, project fields, that also annotate issues with metadata, but only if the issues are in a project. The main gotcha with these if that if you remove an issue from a project, this metadata is lost. It's causing quite some confusion for us now having these somewhat disjoint metadata sources, each with their own semantics. Arguably project fields are the richest, but lacking a multi-valued option which labels have.

A similar dichotomy exists between milestones, and project based date fields with sub-issues, again with different semantics.

It would be interesting to see the thinking behind the data model and semantics of these features, especially how the semantics relate to each other. Was this considered? I do wonder if a more formal theoretical basis for these features would be beneficial?

Thinking ahead to issue workflows (which has vanished from the roadmap) i do wonder if all this makes that task much more complex than it needs to be. The lack of workflows (which are really allowed metadata state transitions) is the biggest bugbear we have with GH issues at the moment. Workflows and especially enforced workflows being a big requirement for larger organisations that have certifications to consider. For example, there's no way to block issues progressing through a project board without some pre-condition being met. Actions would be great for this, but all you can do to enforce is write a convoluted action using the APIs to move things back after they move when they shouldn't. Bots are a sticking plaster over this stuff.

[oliviertassinari]

The thread in the initial issue (during the opt-in phase) https://github.com/orgs/community/discussions/139933#discussioncomment-10885036 touches the same problem. "Issue types" in its current shape seems harmful (less is more).

Org level labels (that appear in all repos) combined with namespaced/nested labels

This would be great. In our case, we have have 3 kind of issue labels: a. Product scope labels (e.g. billing, onboarding) b. Prioritization type labels (e.g. regression, bug, new features, priority: high) c. Skill / kind of work labels (e.g. design, Safari). The notion of issues type feels absurd in our context (too opinionated to help).

Off-topic: Going to amazing for us would be to be able to subscribe to notifications that are only about new issues with specific labels so product owners can be aware of new (a.) Product scope labels.

[alystair]

https://github.com/orgs/community/discussions/16682 scoped labels solve this entirely without added noise. It's the only reason my org sticks to Gitlab at this point.

[simon-abbott]

I agree 100% with using scoped labels + organization labels. Would be a much more flexible solution. Our org has lots of labels already that are in the <category>:<entry> format, and we've been annoyed for years at the lack of ability to sync common tags between all our repos. This solution for types is a step in the right direction at least, but the two solutions described above would have solved all our labeling issues at once. As it stands we still can't sync the rest of our labels across our repos without external tools.

[jpobst]

It would be nice if the issue types were visible on the list of issues in a milestone (ex: https://github.com/dotnet/android/milestone/38).

When looking to prioritize work assigned to a milestone, probably the most important information is whether it is a bug or feature.

[rileybroughten]

Thank you for this feedback! We are aware of this and have plans to bring issue types to this page as well. We will keep you posted on when you can expect this as we know it is an important piece of information to see as you work with milestones!

[rileybroughten]

We do not have a concrete timeline quite yet as we make plans to migrate the milestones, labels, and /issues dashboard pages, but as soon as we have more details we'll be sure to share them with you all!

[jrfnl]

Can an option to disable this be added please ?

As @hyangah @andrewbanchich @@probitcarwyn and @jahirfiquitiva pointed out above, this has a HUGE duplication with labels - and in most repos/organisations, this is already handled via labels.

As a developer, I don't like having to maintain duplicate code in multiple places.
As a maintainer, I don't like having to maintain duplicate classifications for issues in different taxonomies.

The field is just noise I can do without.

Actually, on that note: why does the "Projects" field still show up when the "Projects" feature has been disabled for a repo ? Again: noise I can do without.

[rileybroughten]

Appreciate all of the feedback on this! We will keep you posted for any updates.

[LeaVerou]

@rileybroughten Labels are a workaround. Making it an explicit field is the right way to go, what you're observing here is just the usual migration pains + change aversion.

[probitcarwyn]

I disagree @LeaVerou , if you think about the actual data model underneath this, and especially how you might want certain labels to only apply to certain types, then scoping/nesting is what you end up in that case too. Once you get to there you're back to questionable value of a disjoint metadata field, especially when you think ahead to how you might implement workflows (state machines across label states). Having been on the private preview for a few months now with Issue Types, when to use which (label vs type) and the lack of types on PRs has been a consistent topic of confusion.

[iphydf]

I like having enforcement of a singular "label". I don't want people to label things as feature and bug. Having a field for singular classification is nice on top of the labels to further describe the issue.

[Topher-the-Geek]

We too need an option to disable this field. We deleted the bug, feature and task labels, and we don't want this field. The previous labels and this field provide no value to our workflows for managing issue, but they do create cognitive load for our users filing issues.

[dingo-d]

Can you add the ability to select the issue type in the issue templates? Because currently we are limited to labels, and then manually selecting the type, which is less than ideal 🤷🏼‍♂️

[rileybroughten]

Good suggestion! We're working on getting the public documentation updated to include this field.

[beingminimal]

@rileybroughten projects are not supported in md files issue templates, as they are supported in yml file of issue templates, any ETA?

[rileybroughten]

We don't have an ETA at the moment, I've raised this again with the team and will keep you posted with any updates 👍

[rileybroughten]

Docs have been updated to include type 👍

[trueberryless]

EDIT: There is a bug in the mobile app: When I define the issue type in my form, the option will not show up in the mobile selection menu!

Btw feedback in general: Despite many people not liking that it was not implemented as org-wide labels, I love the new issue type. I assume that one difference is that one issue can have multiple labels but only one type, so this differentiation gives more emphasis to the type. ❤️

As a reference: https://github.com/trueberryless-org/.github/blob/main/.github%2FISSUE_TEMPLATE%2F0_bug_report.yaml#L5

Try creating an issue in this repo... (bug only exists on mobile devices)

[webknjaz]

Feedback: the type field is not documented in the Issue Forms doc. It took some time for me to google this specific discussion to confirm that it's supposed to work.

Action item: Document this outside this discussion @ https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms.

[rileybroughten]

Thank you for this feedback, we'll work on getting the documentation updated!

When making edits to your issue forms, you'll see a note on the right hand side for configuration options.

[rileybroughten]

Docs have been updated!

[webknjaz]

Thanks!

P.S. On the two-week-old comment — I almost never start these via web UI. I'm pretty sure the primary audience of that web view is the first time users. Like with many similar things, I treat these forms as shareable configs. So when I suggest changes in other repos, I look into what I've got in my typical configs and copy from there. Rarely, I'd go check the docs. But it never occurs to me to use the “create file” web page. Once I have a config that I like the shape of, I just copy it into many/all my projects and go from there. There's just no mental model for “has anything changed in the docs?”

[webknjaz]

Feedback: Issue Types don't seem to be available in regular GitHub accounts, only in the orgs (some orgs?)

Suggestion: Make them available to mere mortals. This may be useful to mass-maintainers who organize their repos under personal accounts rather than creating orgs.

Workaround: One would be tempted to create an org just to gain access to such features. It's not a bad thing, it's actually a good way to organize big amounts of projects and get a number of other features that are rather limiting in user accounts. I'm pretty sure people do this for other features already.

[rileybroughten]

Thank you for sharing this feedback @scottdorman. We wanted to provide these to help organizations standardize and classify issues across their repositories, especially in the initial release. We're discussing this internally and will provide updates on any plans to expand them to user-owned repositories in this discussion.

[josegonzalez]

If they aren't available for user accounts, can we disable them in the UI? I have a private personal repo that still shows it as a filter, as way to categorize existing ones, and on issue creation. Since it can't be used, its a bit confusing to have there (I spent a few minutes just now trying to see how to configure it for my repo and/or user).

[k4yt3x]

I would like to advocate for making issue types available for personal repositories as well, given that personal repos can also be large and require extensive issue management.

For example, take my project. Although this is a personal repository, it has over a thousand issues. Currently, I have to implement issue types using labels like type:Bug. Having Jira-like features such as issue types and priority would greatly help in organizing and tracking these issues. I've been looking forward to these features for a long time.

As for why I don’t just create an organization, this repository would be the only one in that org, and I’m the only active maintainer. That setup doesn’t make sense for me. It would be great if I could simply use issue types in my personal repository.

[tats-u]

Why do you discriminate against personal repositories?
I am using this feature in my EMU account and dying for this feature in my repositories.

[JoePfeiffer]

Another reason to make them available to user repositories is I'd like to modify and debug the template in my own repo before changing it in my organization's repo.

[Nicolas-Innocent]

feedback: when using a board display in projects, it would be nice to have a view of this in the toasts. Since space is very limited there, might I suggest a colored bar (option ?)

something like this ?

[rileybroughten]

Thanks for this feedback! You can also choose to show or hide the Type field on items in your board view.

[Nicolas-Innocent]

oh, I realize that, but it displays it mixed in with the labels which kind of defeat the purpose of having them separate (and honestly render them useless if I understand the design purpose of quickly being able to identify a toast type).
The other option might be to display the type tag between the repo and assignee .

[IntegratedQuantum]

I noticed that you can only select between a small number of colors.

I think these colors are too saturated and make the issues tab rather noisy and cluttered (at least in dark mode). Choosing gray for everything fixes it for now, but in the future I would like the option to pick less saturated colors. There should be a color wheel or just a field for the hexcode like for label colors.

[rileybroughten]

Thank you for this suggestion, we have it noted 👍

[jon-nfc]

+1 for a colour wheel or field for html hex code

[beingminimal]

+1

[CalvinWilkinson]

I agree. We need the ability to choose the color just like with labels. But a color wheel and vertical saturation bar would be excellent to make it easy to quickly select colors so we do not have to deal with the hex codes

[alystair]

We're getting issue types before scoped labels? It's been years 😔
https://github.com/orgs/community/discussions/16682

[LukasKalbertodt]

It would be nice to make issue types a repository-level setting. Otherwise, when moving a project to a different org, I imagine weird things will happen. Having that contained in the repository seems more useful to me.

[simon-abbott]

Our org already has issue types in the form of labels, but I can't find any way to bulk-convert from one to the other. Are there any plans to add functionality like the "Convert to discussions" button for switching over to the new format?

Alternately I would love to see support instead for scoped labels with organization-level management (like the way workflow secrets work). That would allow us to keep all our existing tags, just move them up to the org level.

[rileybroughten]

As far as bulk converting there are a few options:

• Utilize the bulk editing capabilities in a project using copy/paste or dragging table cells (see documentation)
• Use the filter bar and quick filter dropdowns to make bulk edits to existing issues.
  
• Use the API to do this programmatically (see "Automating issue types" section above, and note REST API support is coming soon!)

[LeaVerou]

@rileybroughten this is what we did too, but it would be nice to have a way to override the pagination so that folks don't need to do it once per page (and large repos can have A LOT of pages!). Especially since it takes some time to apply bulk actions, and one cannot trigger another bulk action while one is already running.

[andig]

but it would be nice to have a way to override the pagination so that folks don't need to do it once per page

This feedback has been open since the opt-in. Still not working. We have some 10k issues- having everybody write custom tooling to do this at scale is a no-go.

[tooomm]

Hi @rileybroughten, unlike in your screenshot, the Issue Types option is no longer available for me. I saw it like two weeks ago still... 🤔

How to categorize issues in bulk and tag them correctly when bug or feature labels were used before?

[rileybroughten]

We are investigating this, see https://github.com/orgs/community/discussions/148715#discussioncomment-12901668

[lemonpole]

Is it possible to create an issue via the REST API with an issue type?

I could not find this mentioned in the REST API docs and in this post, only GraphQL was used as an example.

• https://docs.github.com/en/rest/issues/issues#create-an-issue

[rileybroughten]

Development is ongoing for managing issue types with the REST API - we hope to release this to you all in the coming weeks 😁

[rileybroughten]

We're starting to roll out support for the REST API, if you'd like to test this early please provide the name of your organization(s) and we can get you access this week. Thank you!

[rileybroughten]

Check out the changelog which details support for issue types in the REST API. Let us know if you have questions or feedback! 🚀

[lemonpole]

Check out the changelog which details support for issue types in the REST API. Let us know if you have questions or feedback! 🚀

Thank you!

Works like a charm.

[cpopetz]

I already did my jira migration to github using the graphql api, but thank you for doing this nonetheless!

[Seldaek]

I wonder why is it not possible to assign types to pull requests? I often create pull requests out of the blue without having an issue first, and now while migrating to issue types I found that I end up with a need to keep Feature/Bug labels just to be able to assign them to PRs.

P.S: Overall I'm quite liking this for organizations with lots of small repos where doing the work of setting up labels on every repo was too much of a hassle. Thanks 👍🏻

[rileybroughten]

Thank you for this feedback! They are scoped to only being present on issues to help you categorize and classify your work, break it down if needed using sub-issues, and report on it so you can understand the breakdown and progress of work across repositories. Then creating or linking a pull request helps you track the code changes and fixes to resolve and close out the bug, task, etc.

[SteveG-tkorp]

Hello,
I agree with @Seldaek, it would be great if the types of issues could be communicated to the PRs, as this would allow the changelog to be generated with PRs sorted by type directly.

Thanks !

[montyclt]

What about enabling organizations to define multiple dropdown fields, each with their own options? For example:

• Type

• • Bug
• • Feature
• • Documentation
• • Meta-issue

• Difficulty

• • Good first issue
• • Standard

• Critical

• • Critical
• • No critical

I usually use Notion due this capacity. A screenshot for reference:

[probitcarwyn]

This has been called scoped labels or nested labels in other comments on this thread. I do think this is what Types should be and it should be unified with labels. See also:

• https://github.com/orgs/community/discussions/16682

[LeaVerou]

Great feature! I agree it would be nice for the list to be customizable.

One bug we noticed: it seems that if an issue is set to an issue type of "Bug" it doesn't show up in the Bugs section, as that is keyed on "bug" labels only. Ideally, it would be an OR.

[rileybroughten]

I agree it would be nice for the list to be customizable.

Could you elaborate how you would like this be done?

One bug we noticed: it seems that if an issue is set to an issue type of "Bug" it doesn't show up in the Bugs section, as that is keyed on "bug" labels only. Ideally, it would be an OR.

What is the Bugs section in this case? If you could provide more details or screenshots on this setup that would be great!

[swissspidy]

The Refined GitHub extension adds a Bugs section, maybe that's what is meant here?

[Deep-Dark-Forest]

I think it's important to have PRs also support type, because in our repository, both PRs and issues use the same classification labels. We can replace the classification labels of the issues with type, but PRs are not feasible.

[turadg]

I expect "PR Type" would add confusion in my org so I'll make the case against it. A PR can have many commits and address multiple issues. For example, both a bug and an enhancement.

defaut issue type examples of Bug and Enhancement overlap with the default lables of Bug and Enhancement

This feature is in preview. Once it lands the defaults will change.

because in our repository, both PRs and issues use the same classification labels

Why is that necessary? If you want to know whether a PR is fixing a bug, isn't that implied by what issue the PR is closing?

[Deep-Dark-Forest]

Why is that necessary? If you want to know whether a PR is fixing a bug, isn't that implied by what issue the PR is closing?

But often, a PR that fixes a bug doesn't close any issues at all. Then we can only use classification labels to classify every kind of PRs.

[jon-nfc]

I don't know if the issue types confusion is a development workflow I've never heard of or lack of information on why issues have types. It has popped up a bit throughout this thread. In the case of the latter.

• Issues are work that needs to be done

• PR are work that is done

With that in mind, labels serve two purpose: to classify for reporting and for an aid in filtering/finding.

Issues are a little more complex. Consider the entire development workflow. Not all stakeholders are developers. So how does a non-technical person communicate a feature to be added to the software? this is where issue types come into play. The common issue types are as follows (and in the hierarchical order):

• Epic = Epic User story. language is non-technical in nature
  An epic user story is generally for an addition that has a lot of moving parts, features/components etc.
• Story = User story. language is non-technical in nature
  A user story describes a small area.
• Feature = Something to be added that more likely than not has many moving parts. language may or may not be non-technical in nature
  A feature, generally, would be used to describe a component/module.
• Task = A single item to be added to the software. language is technical in nature
  A single item to be added to the software

The remaining common issue type is:

• Bug = A problem with the software. language can be both non-technical and technical in nature
  A bug describes something wrong with the software

An Epic, Story and depending on your policies, possibly Feature are all issue types that are generally used by non-developers to communicate a part (or large part) of the software for development. A Bug also falls into the same area as well.

Once you have those issue types the dev workflow moves towards a developer creating a Feature or Task issue that contains the technical details of the work to be done. Outside of planning nearly all of the developers tickets they work on will be Task and Bug issues. Those are the issue that will have a PR directly linked to it. Completion of these issues which would generally have a parent issue type of Feature, story or Epic would then enable the parent to be closed.

This workflow of development opens up the possibility of reporting how long it took to create a feature (duration the parent was open for). In addition and particularly when your software becomes more complex, you can't work on a single feature per release. You can however complete some tasks as part of a release.

I'm personally of the opinion that issue types are an "about time" feature, with the only missing feature being issue dependencies (blocked, blocked by and related). If you would like to see a repo of how issue types can be used, please feel free to look at one of my repos. At the end of the day, issue types are your decision and I hope I've been able to assist with the general gist of what they generally are.

[probitcarwyn]

I like your reply @jon-nfc , the split in thinking as to which role (issure creator vs issue curator) makes use of labels vs types is useful. This is especially the case if you then base your issue template on the type selected.

Perhaps the overlaps in default values for types vs lablels (both have bug and enhancement for example) needs consideration, with some docs on example use cases and flows.

[jon-nfc]

I like your reply @jon-nfc , the split in thinking as to which role (issue creator vs issue curator) makes use of labels vs types is useful. This is especially the case if you then base your issue template on the type selected.

I can't take the credit for what I've explained as it's part of the common development workflow. It does have a name, although it escapes me.

Perhaps the overlaps in default values for types vs lablels (both have bug and enhancement for example) needs consideration, with some docs on example use cases and flows.

Although the labels do overlap with types, they are sensible defaults. If the labels that overlap issue types were removed, with the exception of using conventional commits, how do you determine/filter if a PR fixed a bug? was an enhancement? etc.

I don't know if documentation will help or if it's the answer. Github is a platform for software developers. With that in mind, there is no requirement to document issue types and label usage (outside of their existence) as developers have been professionally trained. However this far from reality, as Github is also used by self taught "software developers." This groups knowledge will range from the "I know boats" through to "very knowledgeable" More recently the IT world has moved into using Github, due to the latest buzzword "GitOPS" I believe this is the group that will possibly struggle with the software DevOPS concepts. Although again, I don't know if documentation will fix the underlying issue of a lack of knowledge.

[Christian-Toney]

How do I sort issue types after creating them? I'm not seeing an option on the dashboard. I can currently workaround this by deleting each type, and re-creating them where I want them but this process is currently tedious.

[rileybroughten]

We have it on our backlog to be able to reorder this list, I'll keep you posted with updates as we start working on it!

[baptisteArno]

My repo is under my personal account (https://github.com/baptisteArno/typebot.io) so I can't use that feature??

[rileybroughten]

Issue types are currently available for organization-owned repositories only. We'll provide updates in this discussion for any plans to expand them to user-owned repositories.

[tats-u]

Let personal repositories use this feature as soon as possible.
I am dying for this feature in my repositories.

[MattMcAdams]

There's already been a lot of feedback in response to issue types being exclusive to orgs but I wanted to point out that this makes a very confusing user experience across the platform.

I would wonder why do some repositories use types and others don't? Aside from feature adoption issues, the fact that some repos straight up can't have types even if the maintainer wanted them, means that this will be a more lasting point of confusion. At least with labels, that's something that feels almost universal and applies to all repositories regardless of ownership.

I'd expect there to be a long period of labels vs types on the platform regardless, but I imagine it would eventually settle down with wider adoption of the types feature (especially if GitHub changes the default set of labels to encourage using types). Keeping types as a feature exclusive to orgs prevents this wider adoption and perpetuates the labels vs type confusion.

There's a number of other great issues raised in this thread, but I do hope y'all consider bringing types to all repos if only for a consistent user experience.

[rileybroughten]

Thank you for this feedback @MattMcAdams - we will provide updates on this discussion with plans and timing of when you can expect to see issue types supported in user-owned repositories as well

[CalvinWilkinson]

I agree with @MattMcAdams on this. I, for one, have a personal organization and manage many different projects, as does a client with a similar setup. Not all projects are handled the same, and are not managed the same. Certain issue types do not apply to one project, but they do to another project. It would be a great feature to have this at the repo level as well.

[stanlrt]

Is there a way to make GH use the type for the automatic branch naming?

E.g. an issue of type Feature leads to a branch named feature/XX-issue-name

[JulesGresset]

Hey, thanks for the feature !

I noticed that's its not available for release template used when for the auto generated release notes

With this example :

The release notes is empty with only the link with the two changes between two tags.

Is it something planned ?

[rileybroughten]

We don't have immediate plans to address this, but I've passed this feedback along to the team. Thank you!

[andrewtheis]

+1 for this feature!

[CloneOfAlex]

Feedback on Issue Types Public Preview

What’s Working Well ✅

1. Improved Organization

   • The ability to classify issues using a shared, consistent taxonomy (bug, task, feature, etc.) makes issue tracking and filtering much easier.
   • Helps maintain a standardized workflow across repositories within an organization.

2. Customizing Default Issue Types

   • Allowing organization administrators to define and manage custom issue types is a great addition.
   • The default options (Bug, Task, Feature) provide a solid starting point.

3. Flexibility in Setting Issue Types

   • The ability to set the issue type when creating an issue or modify it later is useful.
   • The bulk update feature for changing issue types on multiple issues at once is a major convenience.

4. Integration with Projects

   • Being able to filter, sort, and group by issue type within GitHub Projects adds more structure to issue tracking.
   • The Auto-Add to Project Workflow is a helpful automation feature.

5. GraphQL API Support

   • The ability to query and manage issue types via GraphQL API adds more extensibility for power users.

---

Bugs/Issues Encountered 🐛

1. Lack of Issue Type Customization at the Repository Level

   • Currently, issue types are only customizable at the organization level.
   • It would be beneficial if repository admins (not just org admins) could add/edit custom issue types per repo.

2. UI/UX Inconsistencies

   • The issue type selection UI is not always intuitive, especially when updating an existing issue.
   • The placement of the "Type" dropdown in the issue creation and editing screens could be improved for better visibility.

3. Limitations in Automation & API

   • GitHub Actions/Webhooks: While issue types are supported in webhooks, there’s no direct trigger for issue type changes.
   • Would be great to have an on: issueTypeChanged event to trigger workflows based on issue type modifications.

4. Sub-Issues and Issue Type Confusion

   • When creating sub-issues, it’s not always clear whether they inherit the parent’s issue type or need to be manually assigned.
   • A default inheritance option for sub-issues would be useful.

---

Suggested Improvements 💡

1. Allow Custom Issue Types at the Repository Level

   • Not all organizations need global issue types—some teams prefer to define their own per repository.

2. Better Visibility for Issue Type Field in UI

   • Make the issue type more prominent in the issue creation/editing screen.
   • Perhaps preset issue types based on selected templates for smoother workflow.

3. Webhook & Action Enhancements

   • Add a new GitHub Actions event that triggers when an issue type changes.
   • Allow GitHub Actions to set issue types dynamically when creating/modifying issues.

4. Sub-Issue Type Inheritance

   • Provide an option for sub-issues to inherit the type of their parent issue by default.

---

Final Thoughts 📝

The Issue Types feature is a great step forward for structured issue management on GitHub. While it improves organization and automation, a few enhancements—especially repo-level customization, UI improvements, and better webhook support—would make it even more powerful.

Overall, a solid addition to GitHub Issues, and I look forward to future updates! 🚀

---

[rileybroughten]

Webhook & Action Enhancements

Add a new GitHub Actions event that triggers when an issue type changes.
Allow GitHub Actions to set issue types dynamically when creating/modifying issues.

@CloneOfAlex here is the documentation for webhooks when issues are typed and untyped. Let me know if that helps!

[chandanrattan]

Hi, I noticed a bug. When you define value as below then it will throw error that invalid.

issue: "Task"

it work as

issue: 'Task'

[rileybroughten]

Could you provide more details about this error you are seeing, such as any screenshots and how you're performing this?

[vemolista]

Would be great if issue types were available in the GraphQL API and CLI as well.

Concretely

1. issue types are not available as a field on the organization object in the GraphQL API
2. issue type is not available as a field when running gh issue view {number} --json in the cli

[edalzell]

And projects

[rileybroughten]

Here are GraphQL docs for issue type objects and mutations.

Support in the CLI is not yet supported, we will keep you updated on progress there!

[alfred-ai]

So it looks like Github forced this "issue type" to everyone around UTC 15:00, and there is no way to disable it anymore.

[pyscripter]

As you see below:

the header reports 37 open issues, but the list only shows 16. Previously the two numbers would match. Why is that?

[pyscripter]

This appears to have now been fixed.

[simonv3]

This is enabled on our organization and now looks like it's disappeared from our issue management interface, which is deeply annoying because we kind of removed all of our relevant labels with this new feature, not realizing it was a preview? Like we can't bulk assign types anymore?

[rileybroughten]

@simonv3 this is now fixed, let us know if you encounter any other unexpected behaviors!

[simonv3]

Thanks @rileybroughten ! I see it on the filter of the issues list but am still missing it when bulk editing issues, wasn't sure if that was maybe a caching thing or not

[tooomm]

Same here, I see Types as filter:

But not when selecting issues to edit them:

In general it would be helpful if the order follows the same logic in either view:
Filter: [Labels] [Projects] [Milestones] [Assignees] [Types]
Edit (is): [Label] [Assign] [Project] [Milestone]
Edit (should): [Label] [Project] [Milestone] [Assign] [Type]

[rileybroughten]

Thank you for raising this, I've passed it along to the team and will provide updates!

[rileybroughten]

This has been fixed!

[espdev]

It's kind of funny that I can see meaningless filter by Type in my repositories, but can't set issue types at the repository level without having an organization in place. I may not understand the depth of the idea, but it seems that there should be at least a possibility to set issue types at the repository level settings.

[CalvinWilkinson]

I think that repo-level issue types would be highly beneficial for many people and bring a lot of value. 😀

[laymonage]

Would be great if we could change the issue count in the repository's header to only count issues of a certain type (e.g. Bug).

We're generally open to people submitting feature requests as issues, but this results in an inflated issue count. Allowing only a specific issue type to count towards the number would make it a better representative of the project's health.