Great news!

Is setting issue types via issue templates supported? I noticed the template builder (/issues/templates/edit) doesn't show them as an option, and the docs don't appear to show them either.

I would really love to see some more sub-issue/hierarchical information, especially in the repository issues view.

For example:

If I have multiple such features each with their own "UI" task the repository issues view becomes a mess. I could prefix all of the sub-issues with "User login" but then it almost defeats the purpose of having sub-issues in the first place!

Similarly when viewing the sub-issues the parent information is not prominent enough.

This would ideally shown as:

User Login #1 => UI #3

Filtering in projects to only show issues that don't have a parent in the same project

we actively use and love projects and sub-issues, we used tasklists, but have adopted sub-issues instead for most of the use cases.

often times, when looking at a project, we are overwhelmed by the volume of issues
this is why we prefer to filter the project views and only look at the issues without a parent: -has:parent

this filter makes our project board more succinct
sadly, the downside is that we are not noticing issues that have their parent outside the project

we had two different versions of automation to help this before, in the times of 'Tracked by', and now we are looking to develop our third version
we are looking to create a field that indicates whether an issue has a parent inside the project or not. we will then filter for smth like -has_parent_in_project:1

did anyone face this issue? how do you solve this in your organizaions?

dear github team, could you add a way to query for the indicated condition without the custom fields an automation? 🙏

Hello,
whats about the still open problems?
https://github.com/orgs/community/discussions/148713#discussioncomment-12713318

(Cannot create issues in EMU)

I'm so excited for the future of GitHub Issues!

I have some feedback in a couple of areas:

GitHub Projects + Issue Advanced Search

GitHub Projects still lacks support for advanced issue search as part of its filtering capabilities. This is critical, as advanced search is what truly enables more powerful dashboarding when leveraging GitHub Projects.

GitHub Projects + GitHub Issues Automation Capabilities

Automation between GitHub Projects and GitHub Issues feels half-baked. Webhooks make it difficult to fully automate issues/projects ourselves.
For example, if I want to automatically update an issue’s label when it's moved from one project field (e.g., “Category”) to another, there’s no webhook available for GitHub Projects.
The only workaround is to run scheduled jobs to keep everything in sync — but that’s expensive and inefficient.

GitHub Issue / Sub-Issue Rollups & Roll-downs

Sub-issues are opening up a lot of potential for us, but we currently have to build our own automation for syncing parent and child issues.
For example, when a Task is created under a User Story, we want the assignee of the Task to automatically match the parent Story.
To complicate things further, if a Task is created under a Story, we also want the project field (like “Iteration”) to mirror that of the parent Story — which is challenging, especially if the Task isn’t already part of the project.

GitHub Projects View with Sub-Issue / Parent-Issue Grouping

The ability to group issues by parent is great, but there’s a gap when it comes to filtering based on parent issue data.
For instance, we might want to show Tasks on the board grouped by User Story, but only include User Stories that belong to a certain repo — since Tasks might span across multiple repos.
This creates a challenge: we want to filter based on the parent, but we’re limited by grouping via the child.

The reverse is also true — it would be helpful to filter and show only parent issues that contain sub-issues of a specific type. This is a tougher problem, but it’s rooted in the same limitation.

GitHub Projects View with Mixed Issue Types and Static Project Fields

Another challenge arises when using mixed issue types within a single project, each needing different project fields.
For example, we might have a field like “Effort,” which only applies to Tasks, not Stories. Or an “Impact Area” field meant for Bugs, but not Features.
Since all these issue types live in the same project (to maintain correlation and visibility), having static fields for everything becomes cumbersome and semantically unclear.

I'd really like the convert to sub-issue feature to leave the original tick-box item alone. It's nice to use the first comment box in an issue for some narrative giving the sub-issues some extra context.

The additional sub issue list is great in conjunction as it can be ordered.

The last piece to the puzzle is then real dependencies, rather than having to rely on implicit options like priority or date or just the list order.

It’d be super helpful if Project table views supported more advanced filtering like AND, OR, and parentheses—just like the issue search does. For example:
(status:"In Progress" OR status:"Ready") AND (type:"Bug" OR type:"Feature")
This would make it way easier to create custom views for different workflows. Any chance this could be added?

I am finding the sub-issue feature is saving me time - thanks!
I don't seem to be able to re-order the sub-issues inside their parent. I was expecting to be able to drag and drop, e.g. hover and pick up a grab handle. Is there a way of re-ordering the sub-issues?

in the project view, grouping by parent creates an valuable layout with each parent and its sub-issues grouped. however, issues without parents are collected with all the parent issues in a "no-parents" group. i'd very much like the parents to be excluded from the "no parents" group as they are already visible at the top of their respective group of sub-issues

Hello there! Great work with the new issues/subissues and projects view 😄

There are some pain points when using those new features:

Hiding sub issues from main issues view of a repo

In the main issues view of a repository, is there a way to apply a filter that removes subissues from the view?

Let's say I just created an issue, and then split it into many subissues. Now, when I go in the issues view of the repo I am flooded with all those new subissues.

There should be a way to hide those with a filter, maybe is:rootissue or is:issue AND is:parent/is:root?

Defining the default filters for issues on a per-repo basis

So that we can share the set of filters that makes most sense for our use cases with colleagues.
Then, any new person working on a repo would see that default view with the right filters when going to repo/issues.

I know we could share the link with proper filters and use favorites instead.. but this just adds more unnecessary friction.

What is the status of this for GHES (Self Hosted)?

Originally it was slated for this fall on the roadmap.

Then when 3.16 came out, the docs showed it as included.

At some point between 3.16 release and now, the docs changed (though you can still find them via web archive) and all references to sub-issues and types were removed from the 3.16 GHES docs.

The public roadmap now shows the feature tagged with GHES 3.17 instead of 3.16, yet the 3.17 docs make no mention of the feature.
My company its currently on 3.16.3 so I'm unable to check if 3.17 does in fact have the new issues experience with sub-issues and just the docs haven't been updated yet..

Can anyone confirm if [GHES 3.17] does in fact have sub issues?
If so, when will the docs be updated to reflect that?

If not, Why? And when can we expect to see the feature? Working around it has been crippling adoption of Github issues. It's been well over a year we have been waiting for this feature.

In the GitHub Projects board view, are there any plans to improve the "Group by: Parent Issue" experience to work support multi-level issue hierarchies (i.e. grandparent-parent-child relationships)?

Say I have these issues:

• Issue 1
    - Feature 1
      - Task 1
      - Task 2
    - Feature 2
      - Task 3
      - Task 4

• Issue 2
    - Feature 3
      - Task 5
      - Task 6
    - Feature 4
      - Task 7
      - Task 8

If I create a board view with:

• Column by: Status
• Group by: Parent issue

It might look something like:

But I'd like to have something like more along the lines of:

Hi I'm also a fan of the subissues, however could someone elaborate on the imposed subissue limits? I've just hit the 100 subissue limit and actually would like to add more and keep closed issues for history and progress indications. Could this be increased or can I only unlink subissues that are already closed to add more?

Resolving the parent issue doesn't resolve sub issues? I expected it to

Hi Team!

We’re seeing a behavior change when creating a sub-issue from a parent issue. In the “Create sub-issue” dialog, the Projects picker is preselected with all of the parent’s projects. This wasn’t the case before.
This feels like inheritance, but I can’t find documentation that says sub-issues inherit Projects. Is this intended behavior for the new sub-issues experience? If so, is there any doc/changelog that states it, and can admins change the default (e.g., select only the current project, or select none by default)?

Thanks in advance)

@copilot reported as invalid value for assignee in Issue search

When searching within an organization, @copilot is reported as an invalid assignee:

The appropriate issues are returned despite the warning, so the problem appears to be purely cosmetic.

However, there is no warning when the organization filter is removed:

Is there something we should adjust on the organization level?