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.

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.

[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"?

[andrewbanchich]

this seems like a confusing new terminology / concept addition. why not just have "org-level labels"? labels are the standard for classifying issues. i'm not clear on why we need a new concept to be able to do the features listed here, like sorting or filtering.

this seems like it will add a lot of unnecessary duplication, work, and confusion.

[probitcarwyn]

They do indeed feel disjointed. Org level labels (that appear in all repos) combined with namespaced/nested labels would have arguably been more integrated, possibly with an easier migration path to promote certain labels from repos to org level (e.g. bug, enhancement and the other GH default labels).

A good example of this is that you can't have PR types, only labels. So if you have an issue of type "Bug" and you want your PR to carry that metadata too, you're still going to need a "Bug" label.

Types are also single valued which means you have to think carefully to avoid Pigeonhole problem when deciding what types you want.

Being able to at least relate sets of labels (preferably allowing overlapping sets) to types would have been useful too.

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

[seulseul]

How does the new issue type improve workflow management compared to traditional labels?

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

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

[andrybedo]

Is there an expected timeline for when this feature will be implemented?

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

[andrewbanchich]

100℅ - @rileybroughten please consider dropping the issue type feature completely and just add org-wide labels. It's very problematic and unintuitive.

[dbirman]

@rileybroughten Please listen to this feedback! This is all added noise, we already had labels just make them more powerful.

[gitlawr]

I am also looking for a way to opt out of this preview feature. We are comfortable with the existing label management, and it’s flexible enough.

[Haarolean]

I don't like that I can either opt out of everything at once or none at all. Say I like the new issues UI, but I'd rather not see issue types.
Also, I'm concerned that once this feature leaves the preview stage we won't be able to disable issue types again. I'd rather see it released as a thoughtful feature or to be able to disable it eventually.

[alfred-ai]

This needs to be changed to opt-in.

All serious organizations should already have a set of labels for issue type. Even Github gives the default "bug" "new feature" labels when a new repo is created.

[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 🤷🏼‍♂️

[andrewbanchich]

I'd much rather they didn't release this feature at all and just add org-wide labels. Labels is already the standard and making org-wide labels would probably mean everything else would just work out of the box.

[rileybroughten]

You can also specify the issue type in issue templates - when making edits to your issue templates, you'll find the documentation on the right side and can use the type field to specify

[dingo-d]

So it's available in the yml files as well? Because the documentation doesn't have this field mentioned.

Maybe it should be added with the asterisk that it's an organization issue only thing.

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

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

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

[hn88gg]

netstat -ie

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