Issue Types Public Preview (Opt In roll out)

[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:

• Sub-issues Public Preview (Opt In roll out) #139932
• Advanced Search for Issues Public Preview (Opt In roll out) #139934
• Issues: Index, Create and Show Page Updates Public Preview (Opt In roll out) #139935
• Increased Project Item Limits Public Preview #139936

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.

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.

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.

[RanVaknin]

What is the main benefit of using types over using labels of the same name? Ie; use a bug label rather than a type.

[detty-down]

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?

[probitcarwyn]

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.

[phifuh]

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

[xornews]

Does using a type offer better integration with tools or workflows compared to labels?

[fpigeonjr]

Would tech-debt be considered an enhancement or should it be its own label?

[htekdev]

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

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

[CalvinWilkinson]

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?

[luzdealba]

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

Wondering the same thing :D

[dpewaal-iba]

Should tech debt be categorized as an enhancement, or would it be more appropriate to assign it its own label to ensure proper attention and prioritization?

[lppppu]

Will GitHub introduce the ability to customize issue types at the repository level, similar to how labels can be customized? If not, are there plans to increase the number of available issue types beyond the current limit of 10?

[bastimeyer]

There's a bug when trying to filter issue types which contain whitespace when using the dropdown in the issue list header. It doesn't wrap the issue type name in quotes, so the filter query becomes this for example:
is:issue is:open type:plugin issue
instead of
is:issue is:open type:"plugin issue"

The same doesn't happen when clicking the type button directly on an item in the issue list. Here, it properly sets the quotes.

[marty0678]

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

[rileybroughten]

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.

[kanahamppari]

Is there an estimated timeline for fixing the issue with filtering by issue type in sub-tasks when the type includes spaces?

[rileybroughten]

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

[rileybroughten]

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

[bastimeyer]

Btw, is it intentional that when changing issue types that there's no item added to the issue history, like when changing labels?

[diachromemis]

When will the feature to track issue type changes in the issue timeline be supported?

[rileybroughten]

This is coming soon, appreciate your patience on this!

[andrybedo]

Is there an estimated release date for the feature that tracks issue type changes in the issue timeline?

[pannatron]

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

[rileybroughten]

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

[bastimeyer]

Another bit of feedback:

In our repos, we've been labeling issues and their respective PRs with the same labels (for example "plugin issue", "bug", etc.). Since PRs (currently) don't have the type attribute, changing our issue labels with dedicated type attributes would mean that we "disconnect" the issues and their respective PRs (apart from the closing/resolving/fixing links), and we would not be able to fully remove the old type-labels.

So the question is, would it make sense adding types to PRs as well?

[rileybroughten]

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?

[bastimeyer]

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?

[scordio]

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.

[louwers]

@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.

[alexis1314]

What impact would removing old labels from issues have on the connection between issues and related PRs?

[ruuda]

Small detail: on the issues page, if you filter by type, it populates the search box with

is:issue state:open type:Bug 

The casing is inconsistent between these filters, Bug is capitalized while issue and open are not.

[lukewar]

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?

[TWiStErRob]

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

[wojtekmaj]

There should be an option to easily migrate labels to types.

[rileybroughten]

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

[glen-84]

@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.

[wojtekmaj]

There should be a way to filter Issues by a LACK of type, so that PMs could backfill information on already created tickets.

[tay1orjones]

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.

[rileybroughten]

Thank you for this feedback, we have it noted!

[rileybroughten]

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!

[joshjohanning]

And can also use the Type dropdown to filter 😄

[pannatron]

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

[wojtekmaj]

Table header should be sticky to allow easily assigning labels/types/… without scrolling up after selecting an issue further down the list.

[rileybroughten]

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

[wojtekmaj]

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.

[rileybroughten]

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

[CalvinWilkinson]

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

[njzjz]

The issue template can add labels automatically. Will it support the issue types?

[bastimeyer]

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

[njzjz]

Oh, I see. Thanks!

[scordio]

Would you consider displaying the issue type also for pinned issues?

See for example https://github.com/assertj/assertj/issues, where assertj/assertj#3489 is pinned and has issue type New Feature.

[RussKie]

How do I bulk assign a type?

https://github.com/gitextensions/gitextensions/issues?q=sort%3Aupdated-desc+is%3Aopen+label%3A%22type%3A+bug+%3Abug%3A%22

[therealedsheenan]

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.

[scordio]

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.

[RussKie]

Thank you @scordio, that worked!

[TWiStErRob]

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

[beingminimal]

@rileybroughten can you please share when issue types will be supported in gh cli? shouls i create issue in gh cli repo?
Awaiting your response. Thanks

[lukewar]

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

[beingminimal]

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.

[scordio]

Currently, issue types cannot be seen on GitHub Mobile. Is a beta rollout also planned there?

[lukewar]

We are working on adding GitHub Mobile support as well.

[rileybroughten]

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

[acidoxee]

Release changelogs (with a release.yml file) are currently based on labels to form groups (such as new features, bugs, chores...) via changelog: { categories: [{ labels: [ ... ] }] }. Will there be a new kind of matching possible based on issue types rather than labels?

Edit: I just realized that types can't be applied to PRs (or did I look wrong?), so that means we still need labels anyway. So why have two different systems in place? We won't maintain both at the same time.

[joshjohanning]

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

[uday-rana]

Assigning a type in an Issue Form template only works when it's typed in lowercase in the template even if the type name is in fact capitalized.

[louwers]

I get an error:

[louwers]

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

[louwers]

Why don't changes to issue types show the same way as they do for labels?

[ThomasKasene]

Is this what you mean?

[rileybroughten]

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

[warrenb-onware]

When creating a sub-issue from an issue, the dialog to assign a type always drops down, regardless of the available space, and the list of types isn't scrollable.

This means that the types aren't browsable in this context on a laptop screen - you have to know what to search for (unless it's the first 1 or 2)

[rileybroughten]

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

[astendal]

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.

[rileybroughten]

@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 👍

[AdrienFromToulouse]

👋 It seems that the public GraphQL API does not include the issueType property yet in the issue Node. Am I correct?

[jakubkulhan]

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

[Mattamorphic]

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"

[AdrienFromToulouse]

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

[abbluiz-userh]

Hi, I would like to discuss about the fact a PR don't have "issue type". I know, I know, PRs are not issues, but they share with issues the same id auto increment inside a repo and they often stand side by side with issues in projects. If you see the picture above, PRs display blank values on the Type column... I think it's fair to display at least "Pull Request" or something. That's what I did when I had a custom field for my types

[philipdexter]

"Epic" should be a default type

[libo]

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

[rileybroughten]

Check out last week's changelog which includes a higher limit of 25 issue types for an organization, issue types on GitHub Mobile, and improved searching with the has: and no: filters ✨

[DNin01]

The diff for comment edit history isn't looking quite right...

[NoNameProvided]

I would like to be able to sort issue types when I create them and Github to maintain that order when displaying types in a dropdown.

Rationale: Some types are used more than others, now it seems alphabetical order is used, so for us, it means Discussion our least used type is at the top while Technical Task our most used type is at the bottom of the selector.

[beingminimal]

@rileybroughten When we will be able to change order of issues in org settings?

[beingminimal]

@joshjohanning @rileybroughten Any update on this?

[beingminimal]

@labudis can you please share any update on this?

[rileybroughten]

Thank you for raising this. We have this tracked on our end as an improvement to make it easier to organize the list of issue types and will provide an update once we have more details to share 👍

[lister169126]

I'll try to describe this briefly, and I should mention upfront that I don't have the full context.

We needed to implement a search functionality over our projects for various automations, statistics, etc. A colleague started the implementation using query -> node, where items are further filtered by type and the requirements of a given task. The identifier used here is ProjectV2Id.

From this query, I began filtering issues and noticed that it returns approximately half the issues displayed on the page https://github.com/<org>/<repo>/issues. Then I discovered preview features and started processing sub-issues as well, but still about 20% of the issues were missing.

I therefore created an alternative implementation using query -> search, where the query is made using the project ID (in the original form <org>/<numeric_id>, e.g., dogcat/12). Here, I do get all the issues belonging to the project.

Below are two source code examples, one for the node implementation and one for the search implementation. My question is: why does the number of retrieved issues differ? During testing, I also noticed that the results vary based on the use of the GraphQL-Features header, so I suspect this might be related.

Currently, nodes.ts returns 371 issues, while search.ts returns 458 issues.

https://gist.github.com/lister169126/122844511db84556c6f153fd0fad5d11

[lister169126]

It's issue or do we something wrong? Where can I send this as a relevant issue?

[ArunkumarM437]

https://github.com/trending/developers/

This is the trending developer page which has number of developers and it has index for each developer but it shows number in certain records and in string for other people is this mistakenly done or it's just something.

[ArunkumarM437]

It's resolved it seems . Ignore

[jsvgoncalves]

Having a default value on issue creation, or better yet having the default issue type be customizable with a project workflow would be awesome.

[rileybroughten]

Thank you for this suggestion! We've tracked this feedback on our end 👍

[github-staff]

Thank you all for taking the time to share your feedback in this thread. 🙇‍♀️ We’re excited to announce that we have expanded the roll out and made meaningful updates that we believe will enhance your experience. This is a direct reflection of the conversations we’ve had here, and we’re grateful for your role in this process.

As part of this rollout, we’ve created a new feedback discussion to gather your thoughts on the latest updates and ensure we continue to improve. If you’ve already shared your experiences here, we’ve taken your feedback on board. However, if you feel there are points worth revisiting or emphasizing, we encourage you to highlight them again in the new discussions to keep the conversation fresh and relevant.

We look forward to hearing more of our users exploring the evolution of GitHub issues and sharing their thoughts in the new threads! See you there. 👋

[Tjoosten]

hey Github,

Thx foàr this neat selution. But i my opinion it would be useful to support multiple issue types on a report. Example: I have a feature issue type. But it is also include documentation work and such. So we the ticket is more then 1 issue type.

[probitcarwyn]

Arguably those are two different sub-issues of one parent?

[Tjoosten]

Arguably those are two different sub-issues of one parent?

Hmm its possible. For now in my use case we register task lists in the ticket for the idea. What also comes with lists about documentation of that feature. But we have two persons on the project. One writer and a developer. They can select their tickets on the issue type.

(Sorry having a hard time to explain it. )

[probitcarwyn]

I think I understand. In GH at the moment the most natural (but has overhead) mapping is to have an sub-issue per part, each assigned to the respective person. The latest sub-issue preview has an option next to checkbox items to convert to sub-issue (but still can't do a batch of them).

If you compare to Trello where you can assign a checklist item on a card to person, you stat to see the difference in overhead between the approaches. That said, Trello's notification and tracking of "where do I have checklist items to do" is painful.