Sub-issues Public Preview

[github-staff]

Feedback wanted

Thank you for participating in the sub-issues 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
• Issue Types Public Preview #148715
• Advanced Search for Issues Public Preview #148716

Sub-issues

Sub-issues are designed to help you group and manage your issues with a parent/child relationship into a hierarchy.

Adding sub-issues

Any existing issue, where you have write access or above, will now have a 'create sub-issue' option, you can also use the drop down to opt to create an existing issue instead:

Alternatively, you will notice a new relationship section on the sidebar, allowing you to add from a child to a parent.

Viewing sub-issues

As you create sub-issues, you will start building a nested hierarchy of issues under your opening comment.

Clicking one of these issues now allows you to explore them directly from the main issue page via a slide out panel, making it easy to add a comment or update meta-data without losing context.

Working with sub-issues in projects

We have a couple of new fields in projects, sub-issue progress - which gives you a customisable (check out the settings page) progress pill or bar to see how your issues are progressing:

And parent issue - helping you see what the parent item of each issue is. Which works especially well in a group by or slice by format:

We will also shortly release a new workflow to keep a all child issues synced with a project which the parent already belongs to.

Webhooks

Sub-issue webhooks can be enabled at the repository or organization level and can be enabled/disabled separately from issue events.

Webhook events are now fired for the following actions:

• Sub-issue added
• Sub-issue removed
• Parent issue added
• Parent issue removed

GraphQL API

Sub-issues can also be managed via the GraphQL API. Note that these requests will need to include the GraphQL-Features header with a value of sub_issues.

Click to view Fields and Mutations

Fields

subIssuesSummary

Summary of the state of an issue's sub-issues

query summary {
  node(id: "I_123") {
    ... on Issue {
      subIssuesSummary {
        total
        completed
        percentCompleted
      }
    }
  }
}

parent

The parent entity of the issue.

query parent {
  node(id: "I_456") {
    ... on Issue {
      parent {
        title
      }
    }
  }
}

subIssues

A list of sub-issues associated with the Issue.

query subIssues {
  node(id: "I_123") {
    ... on Issue {
      subIssues(first: 10) {
        nodes {
          title
        }
      }
    }
  }
}

Mutations

addSubIssue

Adds a sub-issue to a given issue

If you'd like to replace the exist parent of a sub-issue, provide replaceParent: true

mutation addSubIssue {
  addSubIssue(input: { issueId: "I_123", subIssueId: "I_456" }) {
    issue {
      title
    }
    subIssue {
      title
    }
  }
}

removeSubIssue

Removes a sub-issue from a given issue

mutation removeSubIssue {
  removeSubIssue(input: { issueId: "I_123", subIssueId: "I_456" }) {
    issue {
      title
    }
    subIssue {
      title
    }
  }
}

reprioritizeSubIssue

Reprioritizes a sub-issue to a different position in the parent list.

mutation reprioritizeSubIssue {
  reprioritizeSubIssue(
    input: { issueId: "I_123", subIssueId: "I_456", afterId: "I_789" }
  ) {
    issue {
      title
    }
  }
}

Sub-issue limits

A couple of limits we have implemented that we would love feedback on:

• Sub-issue depth limit: 8
• Max sub-issues per level: 100
• Parents are unique ( an issue can only have one parent)

Next Steps

We would love your feedback on sub-issues and the new issues experience in general as your try it out! Please let us know what you think! 🎉

[huehnerlady]

Hi,

Unfortunately my feedback from here seem not to be implemented yet?

For us that is actually a key feature to be able to use the github issues and move away from Jira 😅

[evi-liu]

Hi @huehnerlady, appreciate the helpful feedback! As you can imagine, we have dozens of feature requests and we prioritize based on customer demand. Unfortunately, we haven't heard enough critical mass of feedback regarding sub-issue bundling on the board view to prioritize it just yet.

In the meantime, I'd suggest using the Table layout with Group by parent issue to see the bundling of sub-issues and parent issues.

[huehnerlady]

We have 2 boards in Jira, one is like I ask you to and one is like you suggest. The table version so far does not work for us unfortunately and we think about getting rid of that. So we need to wait for this feature in order to be able to migrate over 😅

[mavericreal]

Great point. Similar feedback here, but specific to the roadmap view rather than the board view: https://github.com/orgs/community/discussions/148714#discussioncomment-11851148

[jenniyuslauw]

Why hasn’t the feature to bundle sub-issues on the board view been prioritized yet?

[Andrew-Costure]

Hi,

Unfortunately my feedback from here seem not to be implemented yet?

For us that is actually a key feature to be able to use the github issues and move away from Jira 😅

Great feedback...

[tiarakelly]

I've noticed that clicking on the sub-issue progress bar retains the same filter query of the project view. This produces an empty view if the project view was set to show type:features to show the parent child relationship and the child is an epic that type:task.

[tmelliottjr]

👋🏻 Hi there!

Thanks so much for the feedback, this is actually working as currently intended even if a bit odd at first glance.

The parent issue filter is appended to any existing filters for the view and as such, that may result in no parent issue matching the filter criteria.

An alternative we've discussed is replacing the filter entirely with only the parent issue filter. However, it might be more jarring for potentially carefully crafted filters to be removed this way.

I'm going to raise this again with the team as it's not the first time we've seen this feedback.

[tiarakelly]

This is an example of my use case.

Project filter with grouping by parent issue. Here I would also like to click the progress bar and see all child issues.

When looking at a sub-issue if I click on the progress bar, I expect to see all the child issues not just the level:feature issues.

This is what actually happens:

I want to see this

[JamesonRGrieve]

CCing because it wasn't answered in the previous thread and we are now yet another thread down the link-chain.

Your issue for issue dependencies was closed with a forwarding issue (eventually ending up here), but I can't find any other reference to this in the issue it links to, or here which is linked therefrom. What happened to that feature?

[evi-liu]

Hi @JamesonRGrieve, the Dependencies issue is still on our roadmap! Here is the roadmap issue: github/roadmap#1076

[JamesonRGrieve]

Thanks @evi-liu - it might be prudent to have someone link that as a forwarding issue on the issue I linked since that is the first thing that comes up on Google when you search "github issue dependency".

[mavericreal]

Sub-issues in VS Code GitHub Extension

I imagine this is managed by a different team, but since it's highly relevant, I’m linking a related feature request here.

The request suggests enabling the ability to edit and visualize sub-issues directly from the code editor, which could greatly enhance productivity for developers.

You can find the feature request here: microsoft/vscode-pull-request-github#6596

[mavericreal]

Unfold children in roadmap view within projects

It would be great if in a GitHub project with a roadmap view, it was possible to see the children unfolded. Currently, having to open them one by one makes it harder to maintain the hierarchy and get a clear overview of dependencies or sub-tasks.

This feature would improve usability by:

• Preserving the task hierarchy in the roadmap view.
• Reducing the need for repetitive clicks to expand child items.
• Providing a comprehensive overview of tasks and their relationships.

Consider adding an option to toggle "Unfold All" for easier navigation and management.

• Parent 1
  • Child 1
    • Child 1.1
    • Child 1.2
  • Child 2
    • Child 2.1
    • Child 2.2
• Parent 2
  • Child 1
    • Child 1.1
    • Child 1.2
  • Child 2
    • Child 2.1
    • Child 2.2
      ...

[Wilma07]

Why is the ability to unfold children in the roadmap view important for maintaining task hierarchy?

[mavericreal]

Because it helps to group work to be done by its hierarchy, I find it a very helpful mental model. Right now, it's only possible to show one level of hierarchy if you choose group by parent issue. Ideally, you'd be able to click and unfold any issue's children—as long as it fits the filters selected. There is enough space on this view to do that.

[tom-rm-meyer-ISST]

Relax linking restrictions between sub-issues across organizations and users

We do planning stuff across organizations. Different persons create issues that may be linked across the organization to a ticket that had not been created by the same person.

The linkage popup allows to find these strories but does not allow linkage as either the creator OR the organization needs to the same:

I think the restriction to same organization OR user can be relaxed to some logic like "A user is allowed to link, if"

• the user, who tries to link, has the rights to handle sub-issues on both repositories
• the user, who tries to link, shares a team in one of the involved organizations
• the users, who created both issues, are in both organizations

Maybe also I misunderstood the message

[stephanbcbauer]

@tmelliottjr is this just an issue? Or just not implemented? ;) THX

[tmelliottjr]

Thanks for the feedback! The ability to set sub-issues across organizations is something we’re currently evaluating. That being said, we do have dependency management on our roadmap (github/roadmap#1076).

I'm curious, do you have any other use cases for setting sub-issues across organizations other than for dependency management?

[stephanbcbauer]

@tmelliottjr THX for your answer.

Our use Case is the following ⇾ We are working in an open-source GitHub Environment, and we are creating issues for the open-Source community (Developer tasks for different repositories)

Nevertheless, our overall planning is done in another private GitHub Organization. Here we are planning “EPICS”. To achieve these EPICS, we need some issues in our private repository and also the open-source issues. But both, open and private issues add value to our EPIC, and therefore we would like to be able to add all the sub issues to one parent issues (across organizations)

[DavidHuber-NOAA]

Our team would benefit from this feature as well. We have interconnected dependencies to other organizations, including submodules in some of our repositories. Having this feature would not only allow us to track dependencies but create EPICs that include subtasks that must be tackled as part of the overarching task.

[rik]

Keyboard shortcuts clashing

In an issue comment textarea, I can't type the characters Ç and Å on my computer (macOS with English keyboard layout). The keyboard shortcuts for "Create sub-issue" (Opt-Shift-C) and "Add existing issue" (Opt-Shift-A) take precedence when they should not.

[tmelliottjr]

👋🏻 Thanks for raising this, that certainly should not be happening. I'll forward this to the team for fixing.

[tmelliottjr]

@rik Thanks again for raising this. The shortcuts should now be ignored when editing content. Let us know if that is not the case for you.

[rik]

All good! Thank you for a quick turnaround.

[hgenbw]

GroupBy parent issue results on several entries if there is a hierarchy of more than 1-n.
Lets say Goal-Initiative-Task will result in one Group per Initiative with all the Tasks of it and then another group of the goal with all its initiatives.
It will not be ordered.

The ideal behaviour would be to display the groups hierarchically.

[emhane]

labels should be visible on sub-issues, as they are on [tasklist]

[odungern]

Don't see the "Create more sub-issues" button as described in the docu. After creating the first sub-issue, further sub-issues at lower level can be added, but not at the top-level.

Expectation: See the same button 'create sub-issue' as before at the top-level issue.

[tmelliottjr]

When creating a sub-issue a new create issue dialog is shown. At the bottom, you should see a Create more sub-issues checkbox as shown in this screenshot. Please let me know if that's not the case.

[justyn]

Group by: parent issue in Projects has problems

Currently if you "group by: parent issue" it will combine the child issues under their parents in a collapsible way, with a nice progress bar (see screenshot).

But there's a problem with this view, because the "grouped by" headings here "stand in" for the actual parent issue but are not issue lines themselves.

You're therefore forced to either:

• Have duplication of the parent issue (as a grouped by header, and as the issue itself, see screenshot under "no parent issue")
• Exclude the parent issues from the filters for the view, so they are only seen as grouped-by headers, in which case any parent issue (eg an Epic) without any children yet doesn't get displayed at all and so can be forgotten.

I propose a new dedicated view mode for handling the hierarchical grouping of parents, sub-issues whilst allowing the parent issue to remain a regular issue line (with fields) and avoiding duplication.

[tmelliottjr]

👋 This is great feedback and something we've discussed for future improvements to Sub-issues within Projects. We don't have a timeline for such changes, but this is most certainly on our radar.

[mavericreal]

I'm not sure if my proposal here is clear, but the idea is that if we could unfold nested children without the need for grouping by parent, we'd solve this issue. I think the issue in the comment above would get solved as well.

[cmwilson21]

Is this down right now? I have issues that we created sub-issues on and they are not showing up in the parent issue right now.

[cmwilson21]

They are back now but they were gone for at least an hour that I noticed.

[jon-nfc]

I'm a +1 for issues having multiple parents. or adding of a feature to show related, blocked by and blocking.

Whilst the current implementation enables a workflow where you can see a hierarchy of work that needs to be done per group of issues, it lacks any scope to show blocking issues. Being able to have multiple parent issues per issue would then enable visibility to see blocking / blocked by.

[evi-liu]

Being able to show blocked by / blocking is on our roadmap! github/roadmap#1076

[odungern]

I am opposed to it.
A sub-issue is a sub-issue is a sub-issue and thus has exactly one parent.

When we consider a case where we would need two parents, it is rather an issue of its own and others having a dependency on it. (There is no such thing yet in GitHub issues - at least I haven't seen it yet. But please don't misuse sub-issues with multiple parents for such a purpose)

[evi-liu]

Yes, agree with this! Dependency management is on our roadmap! github/roadmap#1076

[michael-hawker]

Yeah, was alarmed with the announcement that task lists are going away, as then with this restriction on sub-issues it'll make tracking certain things more difficult.

[EnderHomunculus]

Hi,

first of all, I am very glad, this feature made it to GitHub 🎉

To have a better overview, I personally would prefere the sub issue section to be under the Relationships Section.
Since descriptions can be longer but I like to navigate through issues through hierachy, without having. to scroll down too much every time

Something like this

[evi-liu]

Thanks for the feedback! We considered showing sub-issues under the relationship section, but found that the sidebar can get too long for issues that can have up to 100 sub-issues and many other metadata like labels and projects information.

[mavericreal]

Is the limit of 100 sub-issues for the first level of sub-issues? Or can you create 100 sub-issues and then for each of those create at the same time 100 more sub-issues?

Eg.:

• Issue 1
  • Sub-issue 1
    • Sub-issue 1.1
    • Sub-issue 1.2
    • ...
    • Sub-issue 1.100
  • Sub-issue 2
  • ...
  • Sub-issue 100

[evi-liu]

The 100 limit is for the first level of sub-issues, so your diagram above is accurate.

[mavericreal]

Great news! Thank you @evi-liu.

[FaGru3n]

I would love to see this feature... because everyone i explain the options on GitHub projects boards ask for this relation to parent and child things... 👍🏼

😍

[FaGru3n]

Question for me @evi-liu do you know when this cool feature will be available for GitHub Enterprise in which version?

[sigubrat]

Loving the new sub issues. It would be wonderful if the parent-child-relationships could be visualised in the Issue list in a repository as well.

Right now when I click Issues I get:

• Sub-issue of A
• Issue B
• Issue A

and I would love the option to group them by parent so that it's similar to in Projects:

• Issue B
• Issue A
  • Sub-issue of A

The order of things isn't important, but the hierarchical nature of issues and sub issues would be nice to have visualised and grouped together.

[evi-liu]

Thanks for the feedback! We will take this into consideration :)

[mathieushopify]

Using sub-issues and grouping in the project board is great for organizing a project.

However, I found that when grouping by the parent, those parents are displayed in the order in which they were created, as opposed to their respective order (when ordering a flat list).

So, let's say you use parent issues to describe deliverables made up of multiple tasks, if there's a deliverable that you need to insert between two existing ones, it is not possible to do so.

Having either a way to apply the manual order to the parents in the project board, or simply sorting them alphabetically would solve this problem.

[evi-liu]

Thank you for the feedback! We are considering changing this to the alphabetic order, so this feedback helps!

[mathieushopify]

@evi-liu Another team ran into the same problem. Any chance of getting a fix soon?

[katypies]

Alphabetic would potentially also be troublesome, in the sense that it's not possible then to see the order that things are prioritized among parent issues. I'd love to be able to make a view that I can drag/prioritize/order the parent issues, and have that "stick" so that the team understands the overall priority at those parent levels

[mathieushopify]

I agree that manual ordering of parents would definitely be the best option, but if I only get that a long time from now, for my use case, I'd be fine with alphabetical as a first step, if that could be done quicker.

[shayfrendt]

Did the reactions emoji picker shrink? 😅

Or did the render size for emoji everywhere on GitHub shrink?

LOVING sub-issues so far. ❤️ 👏🏻

[evi-liu]

This should be fixed now!

[yuanchen-zhu]

I'd like to suggest adding inline editing of at least issue assignee and labels (and potentially more) for sub-issues, to be on feature parity with the tasklist UI (see below). Those features are very useful and are currently our blocker for migrating from tasklist to sub-issues.

[evi-liu]

Thank you for the feedback! We will take this into consideration :)

[hannahhoward]

Hello,

I feel that Group By and Slice by would be greatly enhanced if there were a "root parent issue" field. Specifically, our biggest issue is the need to slice/group at the top level of a sub-issue hierarchy, including everything below.

[Andrew-Costure]

I think you are right. I recommend this solution.

[jtmullen]

Is there a way via the API to get all subissues of an issue? Right now the behavior I am seeing on the API only returns subissues in the same repo as the parent. This is true even when the token used has access to all of the appropriate repos.

[tmelliottjr]

Just did a quick double check myself and both the REST and GraphQL APIs should return sub-issues from all accessible repositories. Can you confirm which API you are using and what scopes your token has?

[jtmullen]

Hello, thanks for your reply - this led me to dig a little deeper. It seems it was an error on our end not actually using the token we thought we were and it is working as expected now.

[CodyALohse]

I like this sub-issue functionality, but I'm really going to miss the Tasklist functionality. I used it to keep track of TDB items and work-in-progress tasks that didn’t feel significant enough to justify creating an issue. While markdown checklists are an option, they require editing the comment each time I want to update or add an item, which isn’t as convenient.

Introducing "Draft" issues seems like the best middle ground for those of us who relied on Tasklists for minor, non-issue-related tasks. I’d prefer to avoid creating sub-issues for these smaller items, and constantly editing comments isn’t ideal. Additionally, in my organization, every new task or sub-task triggers an email notification to the entire team, so I’d rather not spam my coworkers with these minor subtask updates.

What is the likelihood of adding in "Draft" issues?

[evi-liu]

Hi @CodyALohse, appreciate the thoughtful feedback and response here. "Draft" issues, especially draft items in a sub-issues list, are something we're considering. We are continuing to monitor community feedback to prioritize it against our other requests!

[rtibbles]

I agree, I think wherever possible porting as much of the previous tasklist functionality into regular checklists would be ideal - it was an incredibly convenient workflow for iterative planning.

[ElijahLynn]

I just came here to post a new discussion for

Draft Sub-Issues

I think this is going to be a requirement for moving off of Tasklists. So many tasks in a tasklist are basically Draft sub-issues. Projects already has the concept of drafts which is useful for ideation.

Going up a level to Tooling for Problem Decomposition, we need tooling where we don't have to be perfect in the beginning, we need to be sloppy, and get ideas out, and this includes drafting sub-issues.

[EvHaus]

@evi-liu Could you please log a feature request for the GitHub team to add a sub-issues webhook event when sub-issues are re-ordered inside their parent?

[evi-liu]

I have created an issue for this on our backlog!

[tay1orjones]

Could the "convert to sub-issue" function include moving the children tasklist items into the newly created issue?

Right now it just leaves the children in the tasklist, making them appear to become children of the section above it. It's very confusing knowing which ones corresponded to the newly created sub-issue, and then to grab them and put in the new issue is cumbersome as well.

2025-02-20.at.11.15.42-Demo.tasklist.sub.issue.creation.flow.Issue.18655.carbon-design-systemcarbon-Google.Chrome.mp4

[evi-liu]

Thank you for sharing the screen recording! Totally agree - maybe an option after selecting convert to sub-issue to add the nested children as well. I've created an issue for this on our backlog.

[rtibbles]

I feel like this would be addressed by not popping out the converted sub-issue out of the checklist? Then the sub items could remain nested, and when they get converted to a sub-issue they use the immediate parent, not the overall issue.

[ElijahLynn]

Sub-issues needs support for sub-pull-requests in order to replace tasklist

Sub-issues is not currently ready to replace tasklists for my use case, mainly because I cannot link PRs to an issue without them autoclosing the issue. I MUST have a way to link a PR to an issue and mark it to close or not close.

Because I used to just put sub-issues and PRs in one big tasklist, and now that that is going away I can create sub-issues but not sub-pull-requests, which feels disjointed to where the linked PRs live, fwiw. Odd UX.

And if I do the "proper" way and link a pull request in the development section then the first PR that is merged, auto closes the issue, which is a horrible UX if I have multiple PRs. This behavior is a bad UX and needs a way to mark a PR as NOT closing the issue. Just let me link it, and leave the logic to me.

[evi-liu]

And if I do the "proper" way and link a pull request in the development section then the first PR that is merged, auto closes the issue, which is a horrible UX if I have multiple PRs.

This is something we're looking to fix, so merged linked PRs don't auto close the issue! If this was fixed, would you still have a desire to show PRs in the sub-issues list?

[wolfs]

Adding a PR as a sub issue makes sense, since it is a somewhat more simplified way to track work that is happening as part of an epic. And sometimes you create the issue up front - sometimes you don't. I prefer not to have the overhead of creating another issue just to add a PR as a sub issue. In a sense, PRs are unplanned work that are still part of the parent issue, though don't have a separate issue for them.

[ElijahLynn]

This is something we're looking to fix, so merged linked PRs don't auto close the issue!

Yayyyyyyyyyyyy!

If this was fixed, would you still have a desire to show PRs in the sub-issues list?

I think so, because having the PRs on the right of an issue and sub-issues in another place at the bottom seems confusing to me. Tasklists currently let me put PRs and "sub-issues" all together, they were almost awesome, but I couldn't indent items. Another beauty of current Tasklists is that I can stub out tasks and turn them into issues if needed. With the proposed sub-issues I can't really stub out ideas, and since I can't delete issues I am much more likely to be fearful of stubbing out issues.

I think I would like to try a user experience where I can "add sub-issue" and "add existing pull request" and have them all be in a list, and that list is something I can drag and drop the order/priority of.

Going back up to the top, what we are all trying to do is a thing called "problem decomposition", we need tools that help us decompose problems and rapidly get our ideas down so that we can task them out. Some of those ideas will always be bad, and we need a way to see all the ideas, and make some of them go away. We need great problem decomposition tooling.

[ElijahLynn]

Thinking about it more: Sub-tasks would encompass both Sub-issues and Sub-Pull-Requests.

• Add new sub-task (PR OR Issue)
• Add existing sub-task (PR OR Issue

[MarcMeszaros]

We have a similar use case. For traceability, we use a meta top level issue with sub issues capturing various steps of our process. The "implementation" step using PRs (possibly multiple for a given feature), but currently there's no way to add them as sub issues without an intermediate "real" issue.

[rtibbles]

To echo some feedback I've given elsewhere - the inability to segment 'sub-issues' except by creating intermediary issues feels like a bit of a step back from tasklists for me. Creating intermediary parent issues just to be able to add a section header within the sub issues list feels like a bit too much, especially on a repo where we have a very keen open source contributor community, and any opened issue will result in requests to be picked up unless it is assigned to someone.

[MarcMeszaros]

Pull requests as sub-issues

We can't currently add pull requests as sub-issues. We have to use a "real" issue and reference it in the PR with Closes #123. Ideally we would be able to add a PR as a sub-issue since they are in the same number namespace as issues.

Example

In our use case we use a top-level tacking issue as something equivalent to an epic in other system. Each step of our process is a sub-issue using P0 - P4 org level issue types. When each step is complete we close the issue. We use issues/sub-issues (+ comments) as a lightweight "proof of record" system for traceability/audit purposes for an ISO certification.

[JacobAnderson]

Love the feature! Happy with adding parent/child relationships workflow in general.
As others have said I would like pr's as sub-issues.

My biggest hurdle with it so far has been when working to break down an issue into sub-issues I started from a list of checkboxes with notes and sub tasks as indented bulleted check boxes under it. When I go to convert the top level checkbox to a sub-issue It tanks the formatting a bit and doesn't copy over the indented items so I have to go in and copy paste those things to the new sub-issue.

Example:

• Attempt to convert this level to a sub-issue
  • sub task in that sub-issue
  • note for that sub-issue

[rtibbles]

Yeah, I think making the checklist/sub-issue integration completely seamless would make this feature amazing.