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.

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

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

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

[labudis]

@Timmmy-nlb this is on our list of fixes and a team is investigating it. Will keep you posted and sorry for the delay.

[Timmmy-nlb]

But now we no workaround any more!
I hope it will be quick.

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

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