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:

• Sub-issues Public Preview #139932
• Advanced Search for Issues Public Preview #139934
• Issues: Index, Create and Show Page Updates Public Preview #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.

[rileybroughten]

I notice that the default labels for repos now overlap with the default issue types. This likely needs some clarification in the docs and possibly the option to mass migrate from labels to types?

Thank you for this feedback! We'll be evaluating the default labels provided.

As far as bulk migrating, the best ways to do this are to

• 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)

[xPaw]

Filtering only allows you to select 25 issue at once due to pagination. Suggesting to use API is a poor workaround for this. There should be a simple way to migrate from labels to issue types if you're going to roll out essentially a duplicate feature.

Also allow selecting more than 25 issues at once.

[oliviertassinari]

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.

[jrieken]

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

[balupton]

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.

[fpigeonjr]

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

[rileybroughten]

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.

[jaredpar]

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.

[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

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

[rileybroughten]

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

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

[bastimeyer]

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

[rileybroughten]

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 👍

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

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

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

[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

[probitcarwyn]

The only thing so far that's causing some friction for us is issue types being org global, while issue templates are per repo.

In some cases this is useful (certain repos need more info for a given type). But in other cases you want to keep them all in sync.

[jeherve]

As issue types are introduced, would it be possible to extend the list of automations currently available in Project Boards? It would indeed be nice if, when an issue is created in a Project Board (by converting a draft project card into an issue), an issue type could be automatically added to the new issue.

We could consequently imagine having a "Task" issue type added to all project board items as they get created from a board.

[joshjohanning]

Probably best captured by this future roadmap item: github/roadmap#281

[andrasjuhasz]

Bug: if a project has already had a custom "Type" field, then the new, organizational-wide Type attribute does not show up in the list when configuring boards:

[rileybroughten]

If you navigate to the settings page of your project, you'll see a notice under the Type custom field that prompts you to rename it, as we do not support 2 fields with the same name. After you do this you'll be able to use the system Type field. Let me know if you have questions on this!

[andrasjuhasz]

Minor visual bug: the sub-issues progress in table boards have an incorrect left side if the progress is 0%. The left side of the bar is not rounded, and starts somewhat to the right compared to other, non-zero indicators.

[jtmullen]

Once issue types are more integrated with projects I would expect that the custom fields can be set by types. For example, a parent "feature" type issue may have dates schedule where as individual "task" type issues would be assigned to an iteration/sprint. "Bug" types issues could have a ranking field. Right now we have many of these custom fields which show up regardless of type and is confusing to users. Is this a planned functionality?

[rileybroughten]

This is not yet planned. Would you expect/prefer that these fields are project level fields that only exist within the project, or global metadata that is tied to the issue itself, such as all Bug issues having a ranking field?

[jtmullen]

I would expect this to be at the project level. In the status field setting page when editing/creating a field I would expect some sort of checkboxes or other selection method to mark which types the field applies to.

[MarkOSullivan94]

For me enhancement and task are too similar for both to be included in the default issue types.

I'd love to see what types others are using and then perhaps someone could put together a guide on how best to set them up.

Some which I think could be considered:

• Design - The designer(s) are needed to implement designs before this piece of work is approved
• Research / Spike - A period of discovery / exploration is needed before proceeding further
• Dev Ops - A task which involves improving or adjusting the Continuous Integration (CI) and/or Continuous Delivery (CD) pipelines
• QA / Testing - A task which requires the Quality Assurance team to resolve

Feel free to reply with the issue types which have worked for your projects

[klauskjaer]

It would be nice if the hierarchy between the types could be configured. E.g. so that subissues from Epics always get issue type Feature - or whatever...

[alystair]

This seems topical to #16682, scoped labels are so important, and give similar capabilities to labels.

[SistigCh]

I Love GitHub Projects and Sub-issues

Few improvements to consider for Projects and Sub-Issues.

We have some Tasks to do when onboarding a new Customer to our Software. The Opertunity to create an Issue template to automatically generate all the Issues needed (In our case almost 83 with sub Tasks and more)

Would be Great to Create such Tasks with one Click.
A similar soloution to this Jira Issue template

[Konstantinov-Innokentii]

Hey! I'm wondering what is the difference between project's fields & issue types?

[joshjohanning]

@Konstantinov-Innokentii What do you mean by project's fields, just the custom fields you create in a project? For one, the issue types live on the issue whereas custom fields would live in that project and only that project.

If an Issue was added to multiple projects, the issue type would be consistent across.

[JacobwLyman]

Can I get added to this public preview?

[joshjohanning]

@JacobwLyman feel free to sign your org up via https://github.com/features/issues/signup

[htekdev]

Can we add the Type in the payload of issue for event types? This will help in integrating conditional logic in existing automation listening to webhooks ect...

[joshjohanning]

@htekdev I see the type in the issue webhook payload already.

Here is an example creating a new issue:

"{"action":"opened","issue":
...
type":{"id":24308487,"node_id":"IT_kwDOBbB18s4BcusH","name":"Epic","description":"A vision","created_at":"2024-11-14T16:51:12Z","updated_at":"2024-11-14T16:51:53Z"},"

And when I had an issue where a type was added for the first time:

"{"action":"typed","issue"
...
"type":{"id":16138336,"node_id":"IT_kwDOBbB18s4A9kBg","name":"Bug","description":"An unexpected problem or behavior","created_at":"2024-02-11T20:20:41Z","updated_at":"2024-07-26T14:17:25Z"}

[codycooperross]

Is it currently possible to access an issue type in a GH Action yml? For instance, should this work? I'm currently getting a blank value in ISSUE_TYPE.

name: Manage Issue Labels

on:
  issues:
    types:
      - opened
      - edited

jobs:
  manage-labels:
        . . .
    - name: Run script
      env:
        ISSUE_TYPE: ${{ github.event.issue.type.name }}