Update: We now have the beta enabled and I can confirm that sub-issues can be cross-repo.

How did you get this to work? When I try to add a parent to an existing issue, only the issues within the same repo are available to me.

Poderia ter na parte de subissues, os status e a coluna que constam cada uma delas

five qubits built in the circuits, but the function of SparsePauliOp is representing IIZZ in the code which just has four qubits
web:https://learning.quantum.ibm.com/course/variational-algorithm-design/ansatze-and-variational-forms

How did you get this to work? When I try to add a parent to an existing issue, only the issues within the same repo are available to me.

I didn't see an answer to this and am having the same problem. I can't figure out how to add sub-issues that are from another repo.

cross-repo sub-issues within the same organization are supported. by default, the dropdown will show issues from the same repo. if you hit the back button in the header, you'll be taken to a repo picker. the options that appear will be your top repos by a certain criteria, but you can search for others. then proceed with selecting the desired repo and you'll see the issues dropdown for that repo.

Thanks for reporting! This is a known bug, and we have it in our backlog to fix soon.

This would be a game changer for us!

We use issues to document and keep track of client requests.
Often clients will request the same feature - we'd like to see multiple parent issues for one feature

In all honesty, I'd love a way to create a custom field with multi-select capabilities.
This way I can create a separate column titled "Client" and apply it to many issues - basically another type of label - just like the new "Issue Type" feature!

To be honest, I am trying to understand what the difference between a parent or child issue really is for.

Does the intent of a parent relationship mean that it is a dependency and needs to be completed first? I feel like can use a sub-issue to mean a dependency as well.

What are you common use cases for having multiple parent issues?

The dependency example was the first use case that came to my mind when I saw we only have one parent here.

Having multiple parents could enable advanced features like:

• making one parent the tracking issue aka Epic
• making other parent issues dependencies. to make this possible it would require a specific type (yes you introduced that already) to mark an issue as Epic (works already) and another one marking it as Dependency. This requires to add multiple types for an issue since an issue can be Parent/Epic and Dependency at the same time.

I know we go a little bit in the Jira direction here but that one would enable new features like blocking dependant issues as long as it has unclosed dependencies. Right now we go the lightweight way and define dependencies using a task list on top of the issue description.

To try and give a concrete example. We have a pile of issues that relate to a product orientated decision to improve software - e.g. improve logging, that has a sub-issue that related to centralising and protecting logs. This bit of the tree also relates directly to a compliance need that we learned about after the logging improvement epic started. It's useful to associate the centralised logging with the epic and the compliance issue. Two different sources for the same need. Not all logging improvement are a compliance related thing, and not all compliance tasks are logging. There are two roots to the motivation for a common subtree.

• Parents are unique ( an issue can only have one parent)

I also find it quite limiting to only be able to associate a single issue with one parent max.

I use parent issues mostly to categorize "big" features / products within our repository. But it could also be a huge task list, like "refactoring payment integrations".

So a single issue like "Refactor Stripe" might be associated with the parent issue "Payments" (which is the product where we are tracking different payment related features) but at the same time should also be associated with the "Refactoring payment integrations" issue where we would track all payment integrations including this one that need to be refactored.

Thanks for the feedback, @dylanpiera! This is something we're monitoring feedback on during the public preview period.

This debate comes up a lot for us, the ability to put so much detail in PRs means they can end up also tracking work, especially if the PR needs lots of changes. The key difference being that issues happen before work, PR's usually only appear after work is close to ending (in theory).

We frequently get OSS contributions that start as PRs. This does encourage tracking PRs much like issues.

In our team we also think that for light-weight PRs having to create a separate issue just to track it in the parent issue is an unnecessary and distracting overhead.

PRs can already be linked to issues, indeed even cross-repo, via the "Development" section.

I suppose a valid question is whether there's a need for two different ways to relate PRs to issues? I'd prefer a more unified version of "Relationships".

I think I saw a select field when creating a new sub-issue, however not sure if that allows to choose from all templates.

When creating a sub-issue, you should be prompted to select the template/form based on the repository selected. Is it possible you're selecting a repository that doesn't have any associated templates or forms?

Yes, I see that now, sorry. I was getting ahead of myself reading the documentation before I actually had a chance to try it out. Fantastic, it's exactly what I was hoping to see.

Noted! We're trying to find the right balance between keeping the sub-issues decluttered and showing metadata, so good to know that repo names is important. I'll keep monitoring to see how strongly others need this as well.

Agree.

This looks like a mess without repo names.

Here's an even better example — it's pretty obvious when you look at it:

@evi-liu the balance could be: show them if there's more than one, but hide if all are the same repo as the parent issue?

Everything will be good.

This was one of the nice use cases with the [tasklist] beta feature.

Along with being able to reference PRs noted by https://github.com/orgs/community/discussions/139932#discussioncomment-10821434

Thanks for the feedback, y'all! This is a common feature request, and we are looking to bring markdown checklist to sub-issues conversion capability!

I really like the sub-issue feature but his is my biggest annoyance. Converting a task list item into an issue automatically makes the new issue "tracked by" the parent ticket but doesn't make it a sub-issue of the parent, which seems like an obvious thing it should do. Having to manually then add the new issue as a child is tedious.

I really liked the simplicity of tasklists for this.
Mapping out the tasks that are required for the current ticket and checking them off as completed.

Creating whole new issues for each item seem like massive overkill.

I hope tasklists continue to be a thing (and it would be great to get the add button back or a create tasklist option included in the new sub-issue button/menu)

I commonly create "roadmap" issues that contain a variety of "issues" which are really sub-issues. It is incredibly productive to use - [ ] syntax to rough out the list, and then create the issues from the roadmap issue. However, there appears to be no shortcut to do this as sub-issues instead of standalone issues.

Proposal: provide a mechanism for me to rough out an issues list like so, and then create sub issues from them instead of issues. Proposal: provide a mechanism to bulk-add issues that are mentioned in an issue's description as sub issues, similar to the way you can "create issue".

- [ ] issue 1
- [ ] issue 2
- [ ] issue 3

I think that everything will be good.

Hi @kressaty, this should already be working, where you're able to copy a URL to add as a sub-issue. Could you send a screenshot or gif of this not working? We can take a look.

It does appear to be working now; initially it wouldn't "search" outside the issue's repo but all is good now!

We've been using two boards for this kind of separation, parents on one higher level planning board, with sub-issues on the "work" board. Related to your comment, being able to manage which project sub-issues are created on (whether same as parent or not) would be useful.

I'd like to be able to omit issues with a parent

Try -has:parent-issue - that should get you your desired filter!

I just found a quicker way of achieving this for now. When opening up a project, you can add the parent issue as a column. And then you are able to quickly copy/paste from one row to (many) other(s).

We have a dedicated no-code repo that we use to "own" the parent issues.

Apologies for the tedious manual conversion. To be super transparent, we've seen tasklists usage steadily decline while sub-issues continues to grow. Consequently, it's looking less and less worth it for us to invest in a tasklists migration path (compared to improving other sub-issues enhancements, such as other top voted requested mentioned above). For now, I'd recommend using the keyboard shortcuts to help speed up the migration process.

Wouldn't https://github.com/orgs/community/discussions/139932#discussioncomment-10835639 this somewhat ease the migration? Just adjust the markdown and be done?

I vote to keep tasklists in addition to sub-issues! They serve different purposes. Tasklists don't need to be issues. I use tasklists for brainstorming when creating a ticket or reminding me what needs to be done - like "make feature flag ticket", "make qa ticket", "get tech lead to fill out technical implementation section", etc. I have also used them to list out which issues are blocking this issue and what issues is this issue blocking. I liked that I didn't need to hit "edit" and find the list in the md each time to add another thing - the WYSIWYG of the tasklist is the part I enjoyed most. Super quick to add a note without having to switch to edit mode.

Alternatively having a UI like google docs would also solve this - where you can just type in the rendered description instead of having to switch to an edit mode, search around md code to find the place you are looking for and then save it to see if the md you added looks ok. I know most people using github are coders but as a product owner, I am the one creating the issues and not a coder so having the option of a more user-friendly WYSIWYG would be amazing!

I concur. Task list is very efficient to create because you don't have multiple forms to deal with. I just wish we have "Convert to Sub Issue" in addition to "Convert to Issue".

Really liking the beta!

I second CoderNumber1's comment above--while the full hierarchy would be great, expanded parent-issue filters would be a very powerful stopgap.

We are doing it the same way: tracking high-level Epics in a Roadmap board and doing the daily work with Issues in a Kanban board. Sub-issues have really transformed the way we can now interconnect these stories nicely, so thanks for all the great work you've put into this!

Following up on this thread, we have the same problem: nested sub-issues produce more swimlanes in Group By view than intended, and the important top-level Epics get lost in that view. I might suggest that you could offer "Top level parent issue" in the "Group By" selection, would that be a potential solution?

Loving the feature so far! Was wondering if there's any update on this?

+1, any chance this will ship in Q4?

I am new to the beta, but I love the suggestion from sebastianarnold. I would love to be able to group by "Top level parent issue." I am loving the new functionality. So far, this is the one thing that I would really love to see added/changed.

When selecting Add existing issue for sub-issues, you can change the repository you are selecting from with this button:

Thanks. It's not super intuitive, but I can do what I want now.

I run into this every time when linking a PR that fixes an issue. Even though I know that button is there, it feels counter-intuitive. I have the URL on the clipboard, and there's a textfield, I should be able to just paste it, but it doesn't work when the wrong repo is selected.

This is a known bug, and we are looking to resolve it!

We're using Project "Status" fields, which by default are also the column indicators in the Board view for this.

What is missing from this approach though is a state machine to allow or disallow certain transitions (e.g. there's no enforcement of having to visit a column - QA being a good example.).

@probitcarwyn I couldn't reproduce what you said. I mean, I thought the criteria to consider a sub issue as completed, is the issue being closed as completed (maybe even closed as not planned or just "closed"). If the last "status" is used for this (in my case the equivalent of "Done") it wouldn't be enough because maybe I want a previous status to consider the sub issue as completed, as we mentioned, status "QA" or any other status. Maybe my use case is super specific, but I think an issue can travel through a lot of status before getting closed, and we can't sense the real progress of the sub issues if we don't change the criteria

we don't have that functionality yet, but it is in our backlog to support inheriting a parent's metadata by default when creating a sub-issue.

we have an item in our backlog for sub-issues inheriting a parent issue's metadata by default. in the meantime, you could use the automated sub-issues workflow for your project. this does 2 things: first, when enabled, it will automatically import all sub-issues of all parents currently in your project, and second, moving forward, newly added sub-issues of issues in your project will be automatically added to the project as well.

to clarify, do you mean you were looking at a sub-issue, and wanted to add another sub-issue to its parent from the context of that sub-issue? and would like to have some sort of shortcut for that rather than navigating to the parent itself and adding the new sub-issue there?

That's correct.

it hasn't been planned or prioritized at the moment, since allowing this does have additional implications, but we do have it flagged in our backlog for consideration.

👋 the id is required because the REST API for adding a sub-issue is specifically for adding an existing issue as a sub-issue. in the UI we support creating a new issue as a sub-issue, but that effectively does the same thing -- creates an issue, and then adds that issue as a sub-issue.

Ah I understand. Thank you!

Could the docs be updated to reflect that? The current doc is similar to the issue API doc and implies that you create a sub-issue the same way you create an issue, which is confusing.