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.

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 😅

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

I'll add another vote to having additional visual indicators and sortability on the Board view to indicate and reveal that Issues are a Child of a Parent, and let the eye see their direct relationship all at once, no matter where they are. We live and die on the Board, not in the Table views.

Here's a very limited in scope and scale mockup screenshot showing how there is little that helps someone intuit what cards are a sub-issue when you see this appear on a Board, after having added a series of sub-issues to an Issue, besides the small Text of the Parent Issue title.:

I get that a fully fleshed out implementation would be non-trivial, especially if you wanted to continue to give users the option to move Sub-Issues between statuses and other flags independently of the Parent. And of course ideally a 'magnet' behaviour that will attach a sub-issue back to its parent when in the same vertical column would be great?

Or how about a "Reveal Parent & Sub-Issue Relationships" function or toggle, and when a user Selects an issue card, it lights up the web lines to its sub-issues, and highlights/glows each sub-issue card wherever it may be?

Or, to maintain a behaviour similar to what Task Lists provided without having to bring them back, just give a toggle Option on Parent Issues to "Lock" the sub-issues to it, for cases where the issue creators DON'T want users to be able to separate the Children from the Parent, and then the view on the Board could be an Expandable/Collapsible drop-down of the Children from the Parent anytime that Lock is employed.

Another option would be to force some of us into using the "Task" function inside the Issue description text field - but for that, you'd need to make the Task list more robust once again, and reveal it on the face of the card somehow, with a summary count of the incomplete tasks present in the description for that Issue, and other functionality, etc.

👋🏻 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.

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

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

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

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.

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?

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

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.

Same here, we got issues separated into two orgs, because they have different scopes for the same product. Removal of tasklist where I could do that, also totally break the "slice" feature on Github project, since using "Parent issue" is tight to the same org than my Epic. I'm currently trying to hack my way through that, by adding a custom text field in GH project, and slice by that. But having cross-org sub-issues would make all those problems go away :)

+1 on cross-org issue tracking. We could use it as well.

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

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

All good! Thank you for a quick turnaround.

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.

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

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.

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

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

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

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.

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.

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

Yeah, and especially the "add new task" in the rendered window with beta tasklists. With plain tasklists we don't get that and "add new task" really helps with problem decomposition.

I agree with OP, task lists need to be kept.

Why remove a feature that already exists?

The problem task lists solve for us that sub-issues does not. Is that they act as a checklist of items that are required to be done on the issue. In addition, being able to "promote" the checklist item to a sub-issue is also beneficial as sometimes a checklist item will become more.

Due to not knowing when sub-issues were first made public that task lists were being removed. We have also begun to use them along with planning, in this case, epics. Epic task lists do get promoted to a sub-issue. This alone keeps our issue count down, until it's time to begin working on an epic.

I didn't get a chance to use Task Lists before Sub-Issues, but it sounds like they would be preferable to what we're experiencing currently, so here's another vote to bring back Task Lists as an additional feature to Sub-Issues.

Original task lists, unlike what the documentation linked above suggests, also included the very powerful feature of "nested task lists". Sub-issues should not attempt to replace this.

But it does allow you to “template” them for repetitive processes

I second this. The lack of this feature is nearly a deal breaker in our camp.

Hi @aneroid, one thing to look out for when adding sub-issues is that you need at least triage access to both issues.

Although you may be able to create issues in a repository, you may not have the ability to modify metadata, such as labels, assignees, and milestones.

Can you confirm that you are able to perform these actions on the issues in question?

In terms of getting the The provided sub-issue does not exist response, I recommend double checking the value you're providing for sub_issue_id. Although the endpoint accepts an issue number, the sub_issue_id is specifically looking for the resource's ID.

I hope this helps!

Hi @tmelliottjr

you may not have the ability to modify metadata, such as labels, assignees, and milestones. Can you confirm that you are able to perform these actions on the issues in question?

The current API key does allow me to assign labels and team members to tickets. So does that confirm that the key has access to modify metadata?

In terms of getting the The provided sub-issue does not exist response, I recommend double checking the value you're providing for sub_issue_id

Do you mean that the issue should exist? It certainly does, I can access it via the URL immediately after it's created. I even added a 2 second wait after an issue is created before I try to add it as a child issue to another already-existing issue but that didn't help. And to clarify - I can assign labels and people to both the issues I'm trying to link.

Even using the HTTP client in PyCharm and cURL with the example commands in the github docs, the linkage does not work.

Okay, I found the issue with the API calls to add the sub-issue:

Although the endpoint accepts an issue number, the sub_issue_id is specifically looking for the resource's ID.

✅ The sub_issue_id actually takes the "ID" and not the "NUMBER". So instead instead of a sub-issue "number" like 456, it's actually a long id with 10-digits (currently), like "7890123456". In the JSON response for an issue, it's id and not number.

I find this non-obvious and the API documentation does not make this clear. Especially when IDs and Numbers used in the examples are both "small" so ID is easily confused with the Number we see in the URL and webUI.

Thanks for the pointer, @tmelliottjr !

I can't even mark a sub-issue as done from the issue itself.

For this we have been using emoji :heavy_check_mark: ( ✔️ ) as the first char of the sub-issue title to denote the issue is "finished/complete". Here's an example of what it looks like in the sub-issue list.

We chose to use this (the tick in the issue title) as we use conventional commit footers to close the issue on merge to the working branch.

thanks for sharing your work around, and also what a great example of how this UX got hit hard. I mean, do internal GitHubbers have to use this too? What are they doing to work around it?

@ElijahLynn 👋🏻

Thanks so much for raising this. I think it's a completely valid criticism and I can see how this can slow folks down.

I don't have anything else to add at this point, but I have brought this feedback to the team.

@ElijahLynn 👋🏻

... I can see how this can slow folks down.

That feels like a polite way of saying the original feature isn’t coming back; which is what I have been told elsewhere. I also miss the old task lists and now use GitHub less in my classes (I’m an instructor) because my students can no longer use them effectively. Creating dozens of separate issues is not only impractical, it confuses students and clutters the repository.

Thanks for sharing your experience.

Maybe we can at least hijack the issue form with the refined GitHub extension and submittable request to that repository to add back some of this feature.