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! 🎉

Closing Discussion Notice

As we've shipped the GA for Issues today, we are closing this discussion. Please direct all Issues and Projects feedback in the Evolving GitHub Issues and Projects (GA) discussion. Thank you!

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

[mavericohm]

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

[Leadwell-Team]

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.

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

[mavericohm]

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

[mavericohm]

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

[mavericohm]

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

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

[lmazuel]

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

[rzvoncek]

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

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

[mavericohm]

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.

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

[antoinevg]

Please re-consider the removal of task-lists.

They solve a different problem to sub-issues: Often I am responsible for several complex issues at once. Task-lists allow me to easily break down and track the work required, as well as communicating my progress with my team.

Sub-issues are great when responsibility for tasks are shared by multiple team members but, in my view, are not suitable for the use-case above because:

• They're heavy-weight and require more overhead to create and maintain. For example, I will often change my task-lists as information becomes available.
• They end up cluttering the global issue list with things that are only relevant to me and not to my team members.

[ElijahLynn]

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.

[jon-nfc]

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.

[Leadwell-Team]

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.

[cschreib-ibex]

Today I have created a bunch of regular issues, and then decided I wanted to add a parent issue to group them all. After creating the parent issue, I click the arrow next to the "Create sub-issue" button and select "Add existing issue". I am then presented with a list of issues to choose from. So far, so good.

The problem is the list itself: it seems to be listing issues at random. If there is a logic, so far I have not been able to understand it. For example, in this particular instance, instead of showing me the issues I created 10 minutes ago, which would be helpful, the list starts with issues that have already been closed a week ago, and which are entirely irrelevant. I understand that no logic is going to guess my intent exactly, but it seems that prioritizing open issues over closed issues, and issues created/updated recently over older issues, would be desirable?

This may not be a problem specific with sub-issues, to be fair. I seem to have (or have had?) the same problem with the regular # autocomplete (e.g. when writing an issue or PR).

[RonieLabr70031]

Hi

…

On Fri, Mar 7, 2025, 11:02 PM Corentin Schreiber ***@***.***> wrote: Today I have created a bunch of regular issues, and then decided I wanted to add a parent issue to group them all. After creating the parent issue, I click the arrow next to the "Create sub-issue" button and select "Add existing issue". I am then presented with a list of issues to choose from. So far, so good. The problem is the list itself: it seems to be listing issues at random. If there is a logic, so far I have not been able to understand it. For example, in this particular instance, instead of showing me the issues I created 10 minutes ago, which would be helpful, the list starts with issues that have already been closed a week ago, and which are entirely irrelevant. I understand that no logic is going to guess my intent exactly, but it seems that prioritizing open issues over closed issues, and issues created/updated recently over older issues, would be desirable? This may not be a problem specific with sub-issues, to be fair. I seem to have the same problem with the regular # autocomplete (e.g. when writing an issue or PR). — Reply to this email directly, view it on GitHub <#148714 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BM5M2GZE2GCIT5HKANF7QYD2TGYHRAVCNFSM6AAAAABUZSPOD2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBSG43TGMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[blizzardengle]

⛓️‍💥 Broken Task Lists

I'm sure this has already been mentioned, but the original task lists are a critical feature for my personal workflow and, even more so, for my students. Unfortunately, the recent feature previews have broken this functionality. We rely on task lists in many of our courses to help students track progress on tasks such as feature development and team contributions. The new sub-issue feature, which requires creating a new issue for each individual task, is overkill for our needs. It would be much more effective if GitHub could retain the original task list functionality alongside this new sub-issue feature, allowing for a simpler and more efficient way to track progress without the added complexity of managing multiple issues.

[kittydoor]

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.

[mnbf9rca]

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

[lcian]

Very useful feature!!!

I think it would be useful if the "pinned" issues in the repo were displayed as the first entries when selecting Relationship > Add parent.

[mnbf9rca]

How can we use config.yaml to only list "main" issue templates, not sub-issue templates? Or to show different lists depending on whether you're adding a sub-issue or 'parent' issue. I can't find any documentation on the schema for the ISSUE_TEMPLATE/config.yaml file.

[ElijahLynn]

Cannot See Sub-Issue Status

I cannot see the sub-issue status. Only if an issue is marked as "closed" can I see that status. Pretty critical feature in my opinion.

[rick-duck-cove]

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

[shirey]

Is there any plan to support sub-issues from other organizations/users? If not, I'd like to make the request.

I'm in the process of converting tasklists to sub-issue lists. I'm finding that the missing ability to reference issues from other organizations/users has been a big blocker. The applications and services that we are building support several consortia across multiple institutions. As such we need to organize issues (and repos and code) across multiple GitHub organizations. It is critical that we're able to track and organize these issues in a single place.

[aneroid]

Sub-Issues API always responds with "The provided sub-issue does not exist" or "Resource not accessible by personal access token".

Sub-Issues is enabled on the project in question. I can manually add an issue as a sub-issue of another (using the webUI). However, the REST API to Add sub-issues doesn't work.

The Access Token I'm using to create issues has read-write access and I can create issues via the API with it.
But when I try to create a sub-issue, I either get the error "The provided sub-issue does not exist" or "Resource not accessible by personal access token".

The permissions needed for Sub-Issues are identical to those needed for Issues:

Fine-grained access tokens for "Create an issue"
This endpoint works with the following fine-grained token types:

• GitHub App user access tokens
• GitHub App installation access tokens
• Fine-grained personal access tokens

The fine-grained token must have the following permission set:

• "Issues" repository permissions (write)

This is the CURL request, names and numbers changed but all of them exist:

curl -X POST --location "https://api.github.com/repos/MyOrg/MyRepo/issues/123/sub_issues" \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer github_pat_<etc etc>" \
    -H "X-GitHub-Api-Version: 2022-11-28" \
    -d '{
            "sub_issue_id": 456
        }'

[tmelliottjr]

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!

[aneroid]

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.

[aneroid]

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 !

[jrowland-ccc]

It would be nice if converting a list item to a sub-issue used issue templates. Currently you can circumvent the blank_issues_enabled: false using this method.

[tellisnz]

Could we please get the sub-issue progress on the roadmap view? like the 0 / X complete indicator like on other views?

[kkmuffme]

When creating a sub-issue, it only takes the part before any empty lines, and incorrectly reassigns the part after to the previous checklist item.
It should use the whole checklist item, which is correctly highlighted on hover, for the sub-issue. Any text after newlines should be put in the new sub-issue's description.
Right now, it can lead to some significant issues as it messes up the tasks:

sub-issue-missing-parts.mp4

[ElijahLynn]

GitHub is Less Sparkly Now

Removing the beta tasklists that I could edit inline, and even add more without having to edit the issue, made GitHub less usable for me. It made problem decomposition harder, and more tedious. The friction involved with adding a task to the tasklist via edit button with the old school checklists results in too much friction that I don't put in simple sub-tasks anymore.

I'm not going to make a full blown sub-task issue for things I need to do for the issue I'm working on. That is overkill and hurts my brain. I can't even mark a sub-issue as done from the issue itself. And sometimes I have like 50 sub-tasks for a single issue, so I'm supposed to have 50 issues saying things like "fix css", or "send email to xxx", with no context in them?

Disabling editable tasklists and forcing sub-issues feature broke GitHub for me. It was a rushed feature and both the feature itself and the launch of the feature were not well thought through.

GitHub is less sparkly now.

[jon-nfc]

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.

[ElijahLynn]

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?

[tmelliottjr]

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

[blizzardengle]

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

[ElijahLynn]

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.

[atilahorvat]

I need assistance with the grouping issues by parent issue.

Before the Sub-Issues functionality got released, I was using a "Parent Issue" text field (created by me) to assist me to group my issues into tasks and sub-tasks. It was working nicely (apart from me being required to enter the parent issue identifier text into the "Parent Issue" text fields of all "sub-issues"). When the new Sub-Issues functionality was released, my project did not get the field of the new Parent Issue. I think, what happened was that because I already had a field with this name in my project, and upon Sub-Issues release it was not overwritten (which is nice). I then renamed my "Parent Issues" text field to "Parent Issues (old)" in hopes that now the new "Parent Issues" field will show up, but it did not.

I tried manually adding it to the project, but there is no option to create a field with the needed type.

Can someone please help with this topic?

Below I added two screenshots where on one of them is shown the desired state ("Parent Issue", screenshot taken from an unrelated project), and on the other, my current state ("Parent Issue (old)"):