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?

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

[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

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

[iphydf]

I'd like a parent: issue number or issue id in the GitHub REST API. Right now it's a bit of a pain to get an issue tree from the REST API.

[octatone]

Thanks for chiming in! I’ve looped in the team, and we’ll look into this further.

[iphydf]

Regarding multiple parent, I'd like 1 parent per child, but then additional relationships like "blocking", which can be many-to-many.

[iphydf]

curl https://api.github.com/repos/TokTok/qTox/issues/462/sub_issues does not work unauthenticated. So unauthenticated users can know what issues there are, whether they have sub-issues, but can't know which sub-issues those are.

[octatone]

Thank you for your suggestion! It’s in the hands of the team now, and we’ll be reviewing it soon.

[SebastianDadeby]

Thank you for adding a great feature to the github projects!

I'd really like the option of closing all sub-issues when a parent issue is closed. Right now, if working in larger hierarchies, it's kind of a pain to traverse down to every sub-issue if a overlaying parent is removed. Adding an option or dialog when closing an issue which has open sub-issues that closes all remaining open sub-issues would be highly appreciated.

[octatone]

We love hearing your thoughts—thank you! I’ve flagged this with the team, and it’s on our radar.

[huehnerlady]

Can that maybe be achieved with github actions? 🤔

[garethrees]

This is really nice, thanks! One annoying thing is that the event log creates a lot of noise, especially if you create the issue then immediately create the sub issues.

Perhaps the specific sub-issues could be folded up by default in the event log, with a click to reveal:

[evi-liu]

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

[steven-sheehy]

I would like the option to have Field Sum accumulate across multi-hierarchy issues. Currently it only sums the direct children of the parent. Likewise the N of M progress bar only tracks direct children and might benefit from a similar option.

For example, if I have a Points field and a hierarchy of Initiatives -> Epics -> Sub-Epic -> Tasks I'd like to roll up the points so that at any level it accumulates all direct children and their grandchildren's points. This would allow me to track the story points and complexity of the remaining work at any level.

[steven-sheehy]

A small step could be to show cumulative values for numeric columns on parent issues in table view when that column is visible. Right now the parent issue doesn't show any columns.

[evi-liu]

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

[StephenWithPH]

This is a lovely feature. Thank you!

I would be nice if there was cascading behavior in the Expand Sub-issues action.

Given an issue with sub-issues
And at least one of those sub-issues itself has sub-issues
And the top-level issue's sub-issues are currently collapsed
When I click the `Expand Sub-issues` button
Then all of the issue's sub-issues are expanded
And the sub-issues' sub-issues are also expanded

[evi-liu]

Ah, so an "expand all sub-issues" behavior. Got it - we will take this into consideration.

[ashnwade]

When adding a parent to an existing issue, I often find that I have to know the parent issue number or I need to scroll a lot to find the correct issue. I think it would be really helpful if you could sort the list of issues presented when adding a parent to:
(1) have issues with other sub-issues near the top (all of my parent issues have multiple sub-issues)
(2) have issues that are closed at the very bottom of the list (these are not useful to me, but I have to scroll past a bunch of them because they are intermingled)

[evi-liu]

Have you tried using the parent issue's title to find the correct issue?

[ashnwade]

Yes. That's when I run into this problem. Using the issue number works much better because it is unique.
Lots of our issue titles have prefixes that were used to help organize prior to sub-issues, so there is a lot of overlap with naming.

[mloskot]

I would like to be able to add pull requests as sub-issues to a parent issue.

I submit a PR, draft it, collect feedback, discuss it, work on it, merge it. Such PR is a task issue, clearly.
Opening a side-car issue just in order to be able to make it a sub-issue for such PR is redundant and messy.

Why not to allow selecting a pull request to "Add existing issue"?

[ag1rlisagun]

It would be very useful to be able to assign multiple parent issues to 1 child issue. Some issues share a task, but if I want to be able to see the task in the same place as the parent issues, I would have to create a duplicate task for each parent.

[jfrost-mo]

When adding a parent issue from an existing issue a click more than necessary is required as the menu that opens only has a single option:

Instead it should directly open the issue picker and focus the search box, in a similar way to how the other issue sidebar items do:

[Christian-Toney]

I'm thinking it's because they plan to add dependencies soon.

[Christian-Toney]

If the sub-issues per level are maxed out at 100 like this post says, I think I encountered a bug because the app says I'm limited to 50.

[Christian-Toney]

Sub-issue depth limit: 8

Is there a technical reason for limiting the sub-issue depth? You can already create a "pseudo-parent" issue as many times as you want by putting the issue number in the child issues' descriptions.

Sub-issues can be really helpful for dividing up huge features, especially those that are cross-repository. However, sub-issues in one repository are susceptible to this limit if the parent issue is already linked deep in another repository.

[Andre601]

It was recommended I share my feedback from here on this discussion, so here I am.

My suggestion is to add support for setting issue types through issue forms. That way can issues be more easily categorized into the issue types from the start based on what issue form a user is using.