Evolving GitHub Issues and Projects (GA)

[tuves]

We continue to improve how teams can plan, track, and manage their work on GitHub. Following our public preview in January, we're thrilled to announce the general availability of sub-issues, issue types, advanced search, and increased item limits in GitHub Projects 🎉. Here's a detailed look at how these new capabilities can help transform your workflow.

🏗️ Bring structure to your issues with issue types

Consistency is key when managing multiple repositories within an organization. Issue types provide a standardized way to classify and manage your issues. With a shared language across all repositories, you can quickly gauge the progress of your bug backlog, identify high-level initiatives, and understand the breakdown of work in any project. Imagine you're viewing the index page of a repository, and all issues are clearly categorized by type. Or you're using project insights, and it's easy to understand the type of work your team's been spending their time on. This clarity makes it easier to prioritize tasks and effectively allocate effort.

Want to implement issue types in your organization? Learn more about issue types.

🔨 Break it down with sub-issues

Once you've created your feature issue, it's time to break it down into smaller, manageable pieces of work using sub-issues. This lets you traverse the hierarchy of issues, helping you track progress and understand the remaining work at a glance.

Sub-issues provide a nested structure that integrates seamlessly with your projects, giving you a visual representation of progress. Whether you're coordinating a team or working solo, sub-issues ensure nothing falls through the cracks.
labudis marked this conversation as resolved.

Curious to see how sub-issues can help streamline your workflow? Learn more about sub-issues.

🕵️‍♀️ Finding what you need with advanced search

As work progresses, finding the exact issues you need can be simplified with advanced search.

Using AND, OR, and parentheses for nested searches, you can build complex filters to pinpoint the exact set of issues you're looking for from the repository or the global issues dashboard. For example, you can search for issues related to your feature with the query is:issue type:Bug OR type:Feature. This helps you quickly and efficiently find the next issue to pick up.

Ready to refine your searches? Learn more about advanced search.

📈 Expanding project limits

All your issues can also be laid out in a GitHub Project. We've listened to your feedback that you want space for more issues in your projects, so we've expanded the limits from 1,200 to a huge 50,000 items per project! 🎉

With today's general availability announcement, we'll be removing the opt-out option in the coming weeks. Moving forward, we'll also make increased limits your default mode.

✨ Enhancements to the GitHub Issues UI

We've also updated the GitHub Issues UI to make it faster and more intuitive. These updates are designed to enhance your experience without introducing new patterns that could slow you down. Some key improvements include:

• A new filter bar with autocomplete and syntax highlighting on the repository and issues dashboard pages.
• A create more option for faster issue creation, allowing you to quickly return to the creation screen.
• An alphabetical ordering of issue forms and templates based on file name, helping you find and set the right order.
• A copy link button for easily sharing the URL of an issue.
• An increased load more event count from 50 to 150 on long issues.

👀 Your feedback matters

We value your thoughts and feedback. Join this conversation to share your experiences and suggestions.

Explore how GitHub Issues and Projects can enhance your project planning, check out our roadmap, and dive deeper into the features in our documentation.

---

Thank you for being a part of our journey to improve GitHub Issues and Projects. We can't wait to see what you build next! 🎉

[ljstella]

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.

[rileybroughten]

You can use the type key to specify the issue type in issue forms and templates, here is the documentation.

[tellisnz]

@rileybroughten - I have a weird bug where if I add the issue type in my templates and got to /new/choose via a bookmark I immediately get 302 redirected back to /new which is a blank template even though i have blank_issues_enabled: false in my config.yml.

Weirder still, the choose a different template link is there, and if I click it I am allowed to go to /new/choose and see the other templates without redirection, and if I pick one the issue type is set correctly.

[nebkat]

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

[labudis]

Thanks for your feedback! Have you considered using Projects? You would be able to display the parent issue side-by-side in a Table view or create a two-level hierarchical list of issues. More about grouping in Projects.

[nebkat]

Thanks for the suggestion! We are already using grouping in most of our project views for status, repository, etc, so it's hard to fit this into our existing setup. This also has the downside of prioritizing issues with sub-issues, which may not have any significance.

Nevertheless that does seem like a good place for the grouping, and if anything it should be the default behavior in table view (leaving grouping open for other fields).

[beberlei]

This is a real problem, even with projects, because you would don't always group by parent/child in projects, so there are enough views where you would end up with (to keep this example) a list of three or more tickets all named "UI"

[stepashka]

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

[evi-liu]

Thanks for the feedback, @stepashka! I know we chatted about this on a call, but circling back here for visibility:

It sounds like you're looking for a filter like parent.project = X to help surface issues whose parent lives in a specific project. In your case, combining it with the - (exclude) qualifier could also be useful.

This is super helpful, and we’ve heard similar requests around filtering by parent attributes, like parent.type or parent.priority. It’s definitely something we’re hoping to prioritize soon, since I think it would be valuable not just for you, but for a lot of other teams as well!

[10eputzen]

I would love to see GitHub Projects without the dependency on a repository (as mentioned here and without the "dirty" workaround to open a dedicated open repo).
We are starting a Monorepo, so we can't give our clients access to the repository, yet it would be extremely helpful, to use Projects as a Project Management Tool together with our clients.
Right now we have an empty repo where we invited our clients and they can create issues there and we then create subissues that is linked to our main repo. It is not very straight forward and just too much overhead.
Otherwise, it is back to Jira/Monday or Azure Devops :-(

[Timmmy-nlb]

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

(Cannot create issues in EMU)

[Timmmy-nlb]

@labudis Hello, there are some news to this topic?

[labudis]

Hi @Timmmy-nlb, we pushed a fix for this issue late last week and are currently verifying with customers. Could you please confirm if you are still experiencing this issue in your environment?

[Timmmy-nlb]

@labudis No change...

A empty frame.

[labudis]

@Timmmy-nlb Sorry to hear that! Would you be able to create a support ticket for this issue so we can get a little more information about your environment and troubleshoot further? Many thanks.

[Timmmy-nlb]

@labudis Already done: https://support.github.com/ticket/personal/0/3335098
Do you need more information?

[folortin]

When creating an issue referenced from a comment, the child issue should have automatically set the parent issue as "parent"

See this https://github.com/orgs/community/discussions/154569

[simon-abbott]

There's still an issue with inserting new items in the middle of lists. https://github.com/orgs/community/discussions/148713#discussioncomment-11909166

[jordandakota]

The dependency issue was closed when sub-issues came out. I'd still like a way to visualize sub-issues and dependency/blockers directly on the roadmap like a typical gaant.

[htekdev]

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.

[dominicafonso-datum]

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.

[dominicafonso-datum]

@labudis I'd love to hear your thoughts on this. We are considering writing a third party project UI that interfaces with the GitHub API, so we can create dependencies. I suppose it could be possible via actions too, but surely native issue dependencies are coming soon?

[labudis]

Yes, we are planning to ship dependencies in August this year: https://github.com/orgs/community/discussions/162396

[SanctusAnimus]

It was reported that this bug was fixed previously, yet still in new UI i only see myself (and sometimes issue author) in assignees list for existing issues in all our private repos, despite our team having 12 members. Having to constantly search is incredibly inconvenient, please fix this!

Rest of the lists (tags, milestones etc.) load correctly, assignees list is displayed correctly for new issues

[zbrown001]

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?

[beberlei]

To help with automations we would need the ability to create sub-issues directly from issue templates so that we can create a group of combined issues automatically that represent a standardized workflow with multiple assignees.

[alanlawrence]

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?

[evi-liu]

In a sub-issues list, you should see a gripper on the left hand-side to drag and drop.

If you're not seeing it, it may be because of your repository permissions. You need triage, write, admin, or maintain permissions to re-order the sub-issues list.

[alanlawrence]

Thanks for getting back to me. I am the respository owner so I should have all the required permissions. Github co-pilot tells me that:

The ability to reorder sub-issues via drag-and-drop (with a "gripper") is not documented as a standard feature for sub-issues in the GitHub Issues UI. It is possible that you are expecting a feature that is not currently available, or that was available in a beta/private preview and is not yet generally released.

Is the gripper a beta or private preview feature?

[dominicafonso-datum]

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

[JeffreyCA]

+1, the closest native thing we have currently is has:parent-issue, but that would filter away standalone issues without any parents or sub-issues.

[SeeringPhil]

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.

[SeeringPhil]

I'll leave this here for reference:

Hiding sub issues from main view

The no:parent-issue filter does achieve what I had in mind
For instance, this filter: is:issue state:open no:parent-issue

The default filters issue however I can't seem to find a way to solve other than sharing direct links 😞

[bharmann]

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.

[labudis]

Hi @bharmann, the new issues experience including sub-issues, issue types and advanced search will become available in GHES 3.18.

[bharmann]

Thanks for the confirmation. So about 3 more months? Is there any pre release or beta available in the meantime?

[labudis]

@bharmann Could you please submit a support ticket so we can further investigate the possibility of providing earlier access? If you could include your GHES version and company details in the ticket, we’ll be able to review your request and follow up with you privately. Thank you!

[JeffreyCA]

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:

[dominicafonso-datum]

in your example, you are overlooking that the 4 parent issues, issue 1, issue 2, feature 1 and feature 2 are also duplicated in a "no parent issue" group. -has:sub-issue would be great but isn't an option. has:parent is no good because it keeps only sub-issues and not any issues that are standalone. effectively, all issues must be sub-issues

[JeffreyCA]

Right, maybe this needs to be an entirely new "group by" option, or controlled by a separate option on the board view.

[tomasforsman]

First of all, I love being able to use sub-issues.

One thing that is lacking, or unclear, is how copilot agents is supposed to interact with sub-issues and parent issues.

As you can see in this image the agent correctly identifies that it is dependent on the parent issue and checks if that is in place but when it discovers that the code is not in place yet, instead of waiting and either checking back later or waiting for user to tell it to proceed, it starts implementing the missing code itself.

It is unclear how to best subdivide tasks where the parent issue is verified by the sub issue and the sub issue is dependent on the parent-issue. I believe the correct order would be for the agent to work on #79 (parent) and when the code is there for #80 to be implemented that work should start. After that, #80 might discover issues with how #79 has done things and should be able to leave comments on #79, wait for it to be fixed and then continue. Once #80 is ready it should be merged into #79 but not closed so that any further updates after a code review in #79 could trigger a verification task in #80 to see if the new changes have any implications.

Until there is a way to use sub issues with copilot agents there should be documented that the workflow is not yet adapted for agent use and a notice when assigning copilot to an issue that has a sub or parent issue.

If I have simply missed something about how this is supposed to work; just take this as a comment that I find it unclear.

[rvandernoort]

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?

[evi-liu]

Glad to hear you're loving sub-issues! Unfortunately, we currently don't have plans to increase the 100 sub-issue limit as very, very few issues hit this limit. If you’re running into the cap, your best bet is to either unlink some sub-issues or create a new parent issue to continue breaking down the work.

[HotCakeX]

Please add Issue type support to all repositories, not just those in an organization. I find them very useful and i want to use them in repositories that are under my own GitHub account.

[dconnolly]

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

[dominicafonso-datum]

is there a distinction to be made between resolved / done and closed? i agree a closed parent suggests the remaining sub-issues are not required. i see three use cases:

1. Close the sub-issues first as that is the principle of having sub-issues
2. Disassociate sub-issues if they are no longer relevant but still needed independently of the parent
3. If a parent is closed with open sub-issues, then the sub-issues get "Close as not planned"

[labudis]

We can't assume that completing the parent implies that the sub-issues are complete. Other products in the market will not allow you to close the parent issue if there are open child issues inside. However, this might be frustrating if you consider some sub-issues as optional scope. Equally, closing those as not planned would be presumptive because you might wish to detach the issues from the parent after closing it and prioritize that work separately.

Currently, we are giving the ultimate flexibility for users to define what they want to do with sub-issues - close them, remove the parent relationship or leave open within the closed parent.