This ensures that issues are classified consistently across repositories without the varying syntax and management of labels, so you can search for and understand the breakdown of work across all repositories in an organization.

@rileybroughten We have standard labels between repositories, so for us, this isn't helpful. Having shared labels between repositories would be amazing though.

Using issue types alongside sub-issues also allows you to consistently break down your work and view the progress either from the issue or in a project using the Parent issue, Sub-issues progress, and Type fields to build custom views by slicing, sorting, grouping, and filtering. We're looking into how we can further strengthen the relationship and integration between issue types and sub-issues.

We can do the same with labels, I imagine?

I'm probably missing something, with the information available it feels like "Issue Types" shouldn't exist in the first place, they add complexity without solving problems.

Issue types are managed at the organization level for a global classification of an issue, while labels are managed at the repository level.

I like the org alignment but how about org-wide/shared labels? Having a new property seems confusing and breaks all existing workflows that are based on labels. We have a ton of persisted queries that are all using labels. Adding a new property forces us to update them all and will spark discussions about label vs type

I wish Types and Labels were practically equivalent. Across all of Bevry's repos, we have bug, enhancement, ongoing. If I label something as bug it should do the type of Bug. Perhaps Types can have a matched label setting. As a user, their backend implementation doesn't matter to me. I just care about how to sort my issues. And as not everyone browsing my repos are part of this beta, they don't see the types, so I have to keep the labels. I also don't know what tooling I have that depends on the labels, so again I wish that there was a way to use and sync both but only display types instead of their duplicated labels.

Also in the announcement, there was also an ongoing Type or something akin, however I only have three Types (Bug, Enhancement, Task) instead of four.

How do you feel about the distinction between "types" and "labels" when managing issues in a project? Do you think having both can create confusion, or do you prefer having more specific classifications like "types" to organize tasks more efficiently?

We're finding some confusion from using both, especially moving from bug and enhancement labels to types, this is especially the case given you can't use Types on PRs and we were using these labels for automated release notes.

I do sometimes wish you could bind certain labels to certain issue types too, a sub-type of sorts.

We had the same initial confusion. What we ended up with, is that a label should be able to fit on multiple types.

Types:

• Bug
• Collection (group of issues e.x. "Github v1.3.0" listing all of the things u are working on for that release, so that a product owner only needs to open this issue)
• Conversation (A thread for discussing an idea, topic, feedback or question.)
• Proposal
• Task

Labels:

• New feature
• Experiment
• Investigate
• Improvement
• Draft

So e.x. an investigate label can be set on both Bug, Draft, Proposal or task
while a experiment can be set on Draft, Proposal, Task, maybe even some conversations.

We using this as baseline to experiment and further adjust.
Currently we are considering to add.

• Documentation
• Infrastructure / CI/CD

You can customize the set of issue types available for the organization (up to 10) as well as the description to help guide what they should be used for, so you can modify, add, or delete issue types as needed for your organization.

Are there plans to eventually allow this to be customized at the repository level? Asking because in github.com/dotnet we have ~500 repositories. The chance that we can collectively agree on the perfect set of 10 issue types to share is pretty low. At the same time there are a lot of labels I'd like to convert to issue types in the repositories I manage.

I have a comment that proposes a way to make it configurable...

https://github.com/orgs/community/discussions/139933#discussioncomment-10849334

I agree with @jaredpar that the number of issue types should exceed 10. If we can have as many labels as we want, why can't we have as many issue types as we want?

Are there plans to eventually allow this to be customized at the repository level?

Wondering the same thing :D

We're aware of this bug and will provide an update when a fix is available! Thank you for reporting 👍

This bug also occurs when clicking on a type in a sub-task as well. Thanks!

This has been fixed when using the Types dropdown to apply a quick filter when the issue type includes a space 👍 Working on getting it fixed when doing the same from the sub-issue.

We have this bug tracked on our end, I will provide an update when this is resolved. Thank you for your patience on this!

@kanahamppari we just pushed a fix for this, let me know if you still encounter this issue!

We have it on our backlog to support events in the issue timeline so you can see changes over time, we'll provide an update once this is supported in the future 👍

This is coming soon, appreciate your patience on this!

Alternatively, if you're unsure or need to check further:

This is actively being worked on, will provide an update when this is released!

We don't have plans to add types to pull requests. Do you have other automations or workflows that are relying on the issues and their linked pull requests to have the same set of labels?

No, we don't have any label-automations.

However, by moving all our labeled issues to specific issue types and removing the respective old labels from the issues, issues and PRs can't be categorized in the same groups anymore, unless we keep the duplicate labels on the issues. This is pretty bad for us organizing/moderating stuff, and for users browsing/finding stuff.

The new issue types allow for better semantic categorization. Labels which were previously also used for categorizing stuff can now purly be used for adding additional annotations, which is great. But if PRs lack this feature, then nothing is really gained from this, because both systems are very much intertwined.

Why should issues be put into the "bug" category via the issue type attribute, while PRs resolving those kinds of issues can not, and instead still need to be labeled "bug", making both categorization systems incompatible with each other?

On a related use case, we were looking at automation for generating release notes, where issue and PR references would be grouped under a markdown section based on a label.

For example:

• New Features section for all issues and PRs having the new-feature label
• Bug Fixes section for all issues and PRs having the bug label
  and so on.

Generally, an issue holds the label relevant to the release notes. Sometimes, a PR has no corresponding issue and gets the label directly.

When moving to issue types, such PRs without issues won't be included in the release notes, and the project would need to create artificial issues to keep the release note generation consistent.

@rileybroughten It's hard to see which pull requests address bugs and which pull requests address enhancements now...

We used to apply the same label. Now we would need a Bug type and a Bug label, which seems quite inconsistent to me.

Thanks for the feedback. This is similar how labels filtering works today. I am curios would you expect labels also to be lowercased when applying the filter?

You can rename your Types at the org level to be lowercase.

See this comment above for some tips on how you can make bulk updates from using labels to issue types

@rileybroughten

1. Not all of our issues are in projects.
2. Bulk edit is limited to 25 items at a time, and we have thousands (it's not the right tool).
3. The APIs that are listed don't seem to include a bulk filtered update. Something like:

mutation {
  updateIssues(input: {
    filter: { labels: ["bug"] }
    issueTypeId: "ID" # ID for "Bug" type.
  }) {
    issue {
      id
      url
    }
  }
}

This makes it very awkward to switch from labels to types.

Edit:

I suppose a combination of:

search(type: ISSUE, first: 100, query: "label:bug") { id }

(paged)

and:

updateIssue(input: { id: "ID_FROM_PREVIOUS_QUERY", issueTypeId: "ID" }) { id }

... should work.

I think you can do this by stacking multiple individual negated task filters.

is:issue state:open -type:bug -type:task -type:enhancement ...

I agree a no:type would be much better.

Thank you for this feedback, we have it noted!

You can now filter by no:type to find all issues that do not have an issue type. Let me know if you have any questions!

And can also use the Type dropdown to filter 😄

Good idea! A filter for issues without a type would be helpful for backfilling. I'll share this with the team.

Could you provide an example or screen recording of what you are observing?

I'll try!

So when managing properties of an item higher up in the table, all the controls are within my reach:

But if I want to manage an item further down the list, I'm selecting it…

…and scrolling up to see the options to assign labels and issue types.

Oh wait, what was the issue I selected? Let me scroll back down again. Oh, it was this one. Let's scroll up again and add that label.

I understand, thank you for providing more details on this!

I agree with this one for sure. It would be awesome to have it be sticky. 😀

It's in the OP. Click "Issue form with type field" and see the screenshot.

Oh, I see. Thanks!

Im curious about this too. What I usually do as a workaround(My team is using projects btw) is that we copy past values from the columns on the table view. Something like below:

We copy one item and then highlight the columns below and paste it(I assume it would be the same with Type column too.

I don't have any idea how to do bulk from the issues page.

I stumbled across the same and realized there were pull requests between the results, which cannot receive issue types.

Adding is:issue to your search query should bring checkboxes on the left side to allow bulk changes.

Thank you @scordio, that worked!

See also https://github.com/orgs/community/discussions/139933#discussioncomment-10824698

This is something that we plan to work on. Do you have any specific action you would like to see as part of it?

Basic operations with types would be fine like assign, get, remove & change type of issue, as of now this would be fine. Thanks
Here is the issue i have created.

We are working on adding GitHub Mobile support as well.

See the comment below, but you can now view and update issue types on GitHub Mobile!

Issue Types are not planned for PRs at this time https://github.com/orgs/community/discussions/139933#discussioncomment-10824773

I get an error:

Oh this is in a fork that is maybe why it doesn't work.

Is this what you mean?

See the comment here, but we're working on supporting this and it's coming soon 😁

We recently shipped a fix to address this, could you try again and let us know if you continue to see this? Thank you!

This is fixed for me, thank you!

This is fixed when I'm viewing an issue in a project, but when I open the issue directly, I still see the issue type dropdown falling past the bottom of the screen.

@astendal are you able to provide a screenshot of what you're observing? I'm not able to see the case when the issue type dropdown is not scrollable so want to reproduce it so we can look into it on our end 👍

I can confirm that the API doesn't return issueType field for me as well. Any timeline for publishing updated API?

Hey there folks 👋
To use issue types via the GraphQL API you need to provide the header GraphQL-Features with the value issue_types in the POST request to /graphql

(i.e. using curl you'd have -H "GraphQL-Features: issue_types"

Thanks for you reply 🙏 - Is it in the documentation somewhere? Via their graphql explorer it does not seems to work. Will try another way.

Agree! For example we could have an Epic "Tech Debt Q1" that groups different tasks.