Issue Types Private Beta

[rileybroughten]

Thank you for participating in the Issue Types private beta which comes alongside the brand new Issues experience ✨ Please leave your feedback below on what is working well, any bugs you encounter, and what else you’d like to see!

Improvements to Issues

You’ll see an enhanced experience when creating, viewing, and managing your issues on GitHub.

From the repository, we’ve updated the filtering experience to give you autocomplete suggestions so you know how you can build your searches and what qualifiers are supported.

As you create your issues, there is an improved flow when filling out your issue, as well as being able to select Create more to quickly create issues back to back.

Issue types

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

Customizing default issue types

An organization administrator can customize the issue types for the organization from the organization settings "Planning" page in the “Issue types” section. These are available for all repositories in the organization by default, with the ability for administrators to exclude repositories from using issue types.

Organization settings page

Adding a type to an issue

When you create a new issue, you can change the type using the dropdown to the right of the filter bar.

Screen.Recording.2024-03-16.at.1.05.12.PM.mov

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 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, delete, and enable/disable them for repositories, as well as query a repository by issue type.

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.

Note: You can opt out of this experience, which will bring you back to the current experience and remove your access to issue types.

[seymourisdead]

this looks awesome! Is it possible to enroll to private beta for this?

[rileybroughten]

Thank you for your interest in participating! We are enabling the new experience and issue types for a limited number of organizations at this point, but we will post an update here once we are ready to roll this out to a broader audience and gather more feedback! 👍

[seymourisdead]

😔 hope to see it available soon!

[garrettm]

Seconded, looks great and I'm also interested in the beta!

[mshish]

Would love the opportunity to join the private beta and provide feedback. About to build out a backlog from scratch and would like to avoid using a third-party integration to make it manageable.

[rileybroughten]

Thank you for your interest! We are still enabling the new experience and issue types for a limited number of organizations at this point, but we will post an update here once we are ready to roll this out to a broader audience and gather more feedback! 👍

[kalanchan]

hello! I'd like to participate in the beta, and trying out the new issues experience! We were looking into moving our github issues over to a different platform as it lacked the ability to track cross repository dependencies, but this seems like a great start to meeting our needs.

[rileybroughten]

Thank you for your interest! We are still enabling the new experience and issue types for a limited number of organizations at this point, but we will post an update here once we are ready to roll this out to a broader audience and gather more feedback! 👍

[esmarkowski]

This looks great! Would love to participate in the beta.

[rileybroughten]

We are still enabling the new experience and issue types for a limited number of organizations at this point, but we will post an update here once we are ready to roll this out to a broader audience and gather more feedback! 👍

[some-natalie]

Hey @rileybroughten , overall I ✨ love ✨ it!!

However, I find myself toggling it off to bulk unassign users from issues. It'll let me assign myself in bulk, but not remove myself.

[rileybroughten]

@some-natalie thank you for the feedback! I wasn't able to reproduce this when making bulk edits from the repository listing page to assign and then unassign myself, so if you're able to provide a video that would be helpful!

[KevinRaney]

Can I be added to the Private beta please? I can test with a few orgs.

[rileybroughten]

Thank you for your interest in participating! We are enabling the new experience and issue types for a limited number of organizations at this point, but we will post an update here once we are ready to roll this out to a broader audience and gather more feedback! 👍

[akasey123]

Hi,
I am unable to get the Projects gear to populate any tags for status which means that I can't move renewal issues forward to the next stages. I have attached a screenshot of this bug/issue.

[mariaKatz]

Hello,
i've tried the "Issue Types" - nice experience - easy to create and to use. I'm missing the ability to define the hierarchy between types.

[rileybroughten]

Thank you for your feedback @mariaKatz! Could you share some more details on how this would ideally work for your organization and how you'd expect this to work? For example, what is the ideal issue type hierarchy you'd want defined or recommended for your organization?

[mariaKatz]

Hi, Thank you so much for quick response on my suggestion. From my point of view at least we need to be able to define the parent-child relationship between Issue Types: * it means once new type is created, I can define the relation :parent of/child of (or contains/contained or any other name that you that will better define the relation) . Also any of those relations could stay empty. It should look like this(for example): Epic contain Feature, Feature contains task and etc. From other hand, BUG does not related to any type and for it the relation filed/link will remain empty. * ***@***.*** maximal number level in hierarchy as maximal number of types * Each type could have few children, but each child may have 1 parent. * Once that structure is defined on organization level, then during their use you need to follow the hierarchy. It means, for example if you create a "feature", then you need to define to which Epic it's related to and etc. For example: If was defined that Story may contain only BUG or TASK, then there are only possible option that visible in interface ***@***.*** * Also it's required to benign able to have a view (or to be able to create a dashboard) which is based on those relations: easily to see the list of Parent Objects and List of their children. With best regards, Maria Katz System Analyst, Engineering Services Haifa, I2M Platform, Philips IT Philips Medical Systems Technologies Israel Advanced Technology Center, Philips Building 34 [Shield_email] From: Riley Broughten ***@***.***> Sent: Tuesday, May 28, 2024 10:01 PM To: community/community ***@***.***> Cc: Katz, Maria ***@***.***>; Mention ***@***.***> Subject: Re: [community/community] Issue Types Private Beta (Discussion #112806) Caution: This e-mail originated from outside of Philips, be careful for phishing. Thank you for your feedback @mariaKatz<https://github.com/mariaKatz>! Could you share some more details on how this would ideally work for your organization and how you'd expect this to work? For example, what is the ideal issue type hierarchy you'd want defined or recommended for your organization? - Reply to this email directly, view it on GitHub<#112806 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BA3HD7IF3OHBX4ENJOKQATDZETH6RAVCNFSM6AAAAABEZSJHECVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKOBUG4ZDQ>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

…

________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[petewalker]

I appreciate this has been asked by many, but is there any timeline for widening this beta out? We would love to test this, particularly in conjunction with Issue Hierarchies whenever they are available.

[TylerMatteo]

Hello! It's great to see that this feature is in progress! The Issue for Issue Types on the road appears to show that Issue Types are set at the Organization level. I was wondering if any thought has been given to having them be set at project level? Several teams in my org would love them feature but I could see it be challenging to use if we all have to use the same set of Issue Types. In any case, having this feature at all would be a huge win for us!

[nicksloan]

Not with GitHub, but curious. Do you imagine that an issue of a type associated with one project cannot belong to a different project? Or does it just get treated like an untyped issue?

Could you work around this by prefixing issue types so it is clear what project they belong to?

[rileybroughten]

@TylerMatteo how much would you like to customize the set of issue types available within an organization? Would it be project by project, by groups of repos, etc? Curious how granularly you'd like to define these issue types and any examples you have 😄

[christinatx]

it would be good for the selection to be editable even when not the author of the issue (ex: programs team needs to make edits)

[rileybroughten]

@christinatx if you have access to edit the issue you should be able to change the issue type once it is added. You can find the option on the sidebar on the right of the issue body under Change issue type

[DHowett]

The new issues experience does not allow you to search for an Author who is not "known" to the repository.

The old experience let you type in an author name and submit it even if the autocomplete did not find it.

The new experience does not let you submit an author name unless it is a member of the repository.

I manage a fairly large repository with a huge number of non-committer issue filers. If I cannot search by their names, I am lost.

[phillmv]

1. It's noticeably slower than the previous experience. Unscientifically, I'm getting ~3.5s with the new experience and compared to ~2.5s with the old one. We shouldn't be shipping experiences that are slower.
2. i find that "opened [time ago] by foo" is more readable than "foo opened [time ago]"
3. I find that I would prefer to have the "Filters" dropdown, it makes it more discoverable than autocomplete drop down

i.e.

[peckjon]

When using Issue Templates, is there a way to make the Type immutable (or hidden?) so the Issue submitter cannot alter it?

Also, I think (n=1) that the value for Type is case-sensitive in YAML Templates, which would be worth documenting (and changing to "Bug" in the example above to work with our default types)