Add relation between issues

[Gotterbild]

It is often case when one issue blocks another. It will be great to have ability to explicitly set this relation.

Right now in the sidebar there is Linked Pull Requests. There can be additional Related issues, and you could mark any issue in this list as blocked by current issue or as a blocking for current issue.

[mattrosno]

I'm also looking for this. Not so much issue dependency, but using issues for both tasks that get completed, and to track user needs over time.

For example, let's say you use a repository to track job stories, jobs to be done, or any flavor of user outcomes that you continuously address. You also have a repository with code and normal issues that get completed per release, sprint, task, etc.

I'm wanting issues to be related to other issues as a named relationship. For example, development tasks are issues that have a custom relation property named "Addresses" where you are able to select one or many job story issues.

In the new table view, you could see which user outcomes are being addressed in each development task. Or you could have a project view with the inverse so you could primarily view the job story issues and which development tasks are addressing each job story.

Custom relations are what make Notion and Airtable so powerful, with the downside of them being separate system of records from where the work is getting done - GitHub.

Unless I'm missing something, per the marketing page, how are relationships getting tracked? Or is it just currently issues referencing other issues in their timelines? If so, that's great as an audit trail, but not so great for product planning / management.

[nebbles]

I came here to either upvote or request this myself. We currently use Shortcut (formerly Clubhouse) for the bulk of our ticket management, but I would love to be able to migrate the team at some point in the future.

Shortcut has the ability to add related issues and designate a particular type in the relation (related/blocking/blocked by/duplicates/duplicated by).

All related issues are then grouped into a neat list for reference (similar to linked PRs in GitHub's side bar)

[coot]

An idea to consider would be to add a field type (next to Text, SingleSelect, etc) which allows to list multiple issues or PRs. The meaning of it would be left to the user, e.g. what kind of relation is it.

[sophec]

This is a key missing feature for me as well. Since projects can span multiple repositories, one should also be able to mark an issue as dependent on an issue in another repository.

[macnicnac]

Exactly also looking for this!

[samhld]

I'm also looking for this!

[omerbensaadon]

Hey folks! We're working on a more robust implementation of precisely this!

For now, you can use Task lists for this functionality:

https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists

[michael-hawker]

I think that may cover some scenarios, but not all. For instance, I may want to link an issue specifically to its "Parent" issue.

So being able to have a custom field type of 'issue' for instance and let me select/link to an issue as a value of that field would be great for that.

But it may also just be a list of other random PRs/issues/discussions that I want to track as 'related'. A task list may cover that but has to live in the issue somewhere vs. just being part of the project board the team uses.

[JavierSegoviaCordoba]

@omerbensaadon any update?

[Gary-H9]

👋 @omerbensaadon same question as above - is there any update? Even if this is no longer being looked at it would be good to know that's the case.

Echoing the above I think this would offer real value. This is something our product/delivery managers expect if they migrate from JIRA or ZenHub.

[danielgomezrico]

This is a blocked beta that is not accepting new users, so maybe this will not fix the requirement

[maliberty]

@omerbensaadon can you give an update on the plans beyond task lists? The "For now" is 1.5 years old

[robopzet]

As far as I understand task lists do not allow the definition of specific relationships, they are just links in the text.
Still waiting for a way to define dependencies between issues and view them, e.g. in a tree or gantt chart, or at least an ordered list.

[michael-hawker]

I generally find myself going to two separate issues and having them reference each other to get the nice link to appear in the feed of each:

This doesn't scale well beyond linking two issues together. Especially, as it's one sided, if someone just mentions an issue in their comment like this:

It only gets visibility more on the feed of the other linked issue:

It'd be really nice for the side panel to have a complete list of issues that are referencing this one and that this one references:

For the above example, from this issue, I would just have a summary and see a list of related issues something like:

• WinUI Packaged projects throws Markup.XamlParseException: 'XAML parsing failed.'  microsoft/microsoft-ui-xaml#6452 (currently buried in a comment)
• Unable to consume custom and/or templated control using nuget packages in WinUi 3 C#/.Net microsoft/microsoft-ui-xaml#7830 (down at the bottom of the issue in the feed)

[dachosen1]

I'm also looking for this feature. Is the GitHub product team monitoring this discussion? It seems that this issue has been outstanding for quite some time, yet the feature still doesn't exist.

[joeyfigaro]

Issue dependencies have been requested since 2014 with no real movement, unfortunately.

[JyotiBB]

It seems interesting to learn that the Projects and Issues team might be considering adding a dependency to an issue.

[harrisonhoward]

Issue relationships are important for projects of any size. If I have an issue that can't be completed due to a dependency on a different issue. I have no way of linking those together other than "mentioning" it in the comments.

Tracking these isn't possible. I think a good example of a good way to implement an issue tracker is JIRA, the platform is more advanced but the simplicity of linking issues is something GitHub would benefit from, especially for smaller projects. The growth of the projects is being held back by this very simple feature.

[joeyfigaro]

If the product team needs inspiration on how this could/might work, Linear does a beautiful job of managing relationships between tickets.

[AleixMT]

Thank you for the Linear recommendation, if you use the GitHub integration I think it does the job. I also think that the team could use some inspiration from GitLab, since this feature is completely implemented there:

[RokeJulianLockhart]

GitLab supports this, as https://gitlab.com/gitlab-org/gitlab/-/blob/c03c1be71de6f26f19862ee203084717dbf4c792/doc/user/project/issues/related_issues.md#add-a-linked-issue explains. I suggest that you move there. I have.

[kelly-sovacool]

Trello does this very well, it would be nice to have similar functionality for GitHub Projects with the roadmap view.

[azenMatt]

Hi everyone - we currently have a beta in progress for this! You can see more info here:

• Sub-issues Private Beta #131957

Access to that beta also give you access to:

• Issue Types Private Beta: Feedback wanted! #112806
• Issues: Index, Create and Show page updates #132506

If you would like to join this beta - please let me know your organization names below and I can add you in. I will add a reaction to your comment once I have added you. Thanks! and please share your feedback once you have tried it!

[ruca-sential]

Please add to the projects under https://github.com/orgs/Passential to this beta. The users are: ruca-sential & CS-Passential. Thank you!!

[stbrody]

Sub-issues is a great feature and I'm excited for it to roll out. But IMO that's not the same as relations between issues. There are lots of different types of relationships I may want to express between issues beyond just parent/child relationships. For example: is blocking / is blocked by, duplicate of / is duplicated by, is related to, documents / is documented by, tests / is tested by, etc

[prossm]

Thank you @azenMatt The team at Idealist.org is interested!

https://github.com/orgs/idealist7

[toddjonker]

Sub-issues are effectively the opposite of blocking relationships: a sub-issue is sensibly assumed to be required before this task can be completed, but a blocked-issue is something that cannot happen until after this task is completed.

I just tried to model a blocking issue as subtasks of the blocked issues, but an issue cannot have multiple parents. So we're left with use subtasks "against the grain" which is not a satisfying long-term solution.

[azenMatt]

We have dependencies coming up on the roadmap, I can see that marking this as answered creates confusion that sub-issues considers this 'done' rather than being a first step so i'l go ahead and mark as unanswered :)

[loeffel-io]

hey @azenMatt, thanks for inviting! there is an bug i think

[loeffel-io]

now it works somehow, but it would be really great so see the hierarchy in the board

[loeffel-io]

a view like this would be a game changer btw

https://trello.com/power-ups/6333f76a988ceb01e68c006e/dependencies-graph

[azenMatt]

you should be able to customise what you can see on the board in the views 'field' menu:

here you can pick to see the parent issue. Or the roll up for progress

[jvani]

@azenMatt as a related feature request, if we story point issues using a GH Project field it would be useful to see progress by story points of child issues.

[maliberty]

@azenMatt what is the timeline to release to production? I'm trying to see if I want to beta or just wait. Thanks.

[azenMatt]

not long, a few weeks maybe

[azenMatt]

Hi all - this is now in public preview! https://github.blog/changelog/2024-10-01-evolving-github-issues-public-preview/

Please sign up using that link if you would like access :)

[wodow]

OP's original question is about issues blocking issues, but "block" doesn't appear in that blog post. Can we use the new issues features to record one issue blocking another?

[justyn]

Yes @azenMatt this discussion was about blocking issues - what is the status of that? Is that abandoned in favour only of this looser arrangement (one issue is a sub-issue of another)

[scottconnerly]

github/roadmap#956 looks like it got pushed back to 2025 Q2. Is that accurate @azenMatt ?

[demisx]

@azenMatt Can we please 🙏🏻 get an update on this feature?

[AleixMT]

At least I would like to know how much more I will have to wait for this feature to come to official GitHub

[stbrody]

I made this comment on a different post in this thread (https://github.com/orgs/community/discussions/4928#discussioncomment-11353058), but re-posting here for visibility:

Sub-issues is a great feature and I'm excited for it to roll out. But IMHO that's not the same as relations between issues. There are lots of different types of relationships I may want to express between issues beyond just parent/child relationships. For example: is blocking / is blocked by, duplicate of / is duplicated by, is related to, documents / is documented by, tests / is tested by, etc

I think this issue has been closed incorrectly. I do not believe the linked feature of sub-issues actually addresses the request that this post represents. I believe this issue should be re-opened to capture the fact that there is still an outstanding feature request here that has not been addressed.

[AleixMT]

Totally agree. Sub-issues do not address this feature request.

[stbrody]

@azenMatt @samus-aran

[lucianomlima]

You're right.

[Norbiros]

I've noticed a limitation with sub-issues: each sub-issue can only have one parent. This restricts our ability to properly represent relationships like is blocking or is blocked by.

[AleixMT]

@azenMatt how much time until it's in production? Thank you

[sdepouw]

Chiming in here: "Sub-issues" is indeed insufficient. Compare with Azure DevOps.

You can't even use sub-issues for this purpose. Say you have "issue 5", which blocks "issue 6" and "issue 7". You might say "set issue 5 as a sub-issue for 6 and 7", but GitHub doesn't allow this (you can set it to 6 or 7, but not both).

[Blackjacx]

We have exactly the same issue. Our Backlog is in a dedicated repo while iOS/Android teams work on their own repos. Now each team of course wants their epic tickets which group sub issues but the product owners, that manage the backlog also would like to use the new sub issues feature¹ to visualize progress on the kanban board.

But both is not possible 😔

Footnotes

1. Kudos to the GH team btw. this looks really nice 👍 ↩

[Thiago-Morais]

Sub-issues is a "1 to many" relation, but many relations require a "many to many" relation like dependency/blocking

Example:
Issue 1 is blocked by Issue 2 and Issue 3 which both are blocked by Issue 4

You can't do this with Sub-Issues

[azenMatt]

A quick update on this, we are working on dependencies as the next relationship type following our work on sub-issues and expect to have something out with you all soon!

[prossm]

Thank you! We already made the switch to Shortcut (since Pivotal Tracker is no more as of 4/30). But it will be cool to check this out for future projects.

[s3rg1o7]

is there an expected release time for the "is blocked by" relationship?

[stbrody]

I'm surprised by the decision to roll out each new relationship type independently, vs having a single generic relationship feature where users can add custom labels for the type of the relationship? Similar to what Jira does. That would enable addressing all kinds of relationships (depends-on, blocked-by, related-to, documented-by, tested-by, etc) all at once.

[grafana-dee]

will happily provide testing of this functionality if needed... or at least happy to work with a PM on it.

the hope is for something that maps a bi-directional relationship between GitHub issues across repos (ideally across orgs, but within an org is good).

inspiration should be:

• JIRA https://confluence.atlassian.com/adminjiraserver/configuring-issue-linking-938847862.html (solid implementation)
• Gitlab https://gitlab.com/gitlab-org/gitlab/-/blob/c03c1be71de6f26f19862ee203084717dbf4c792/doc/user/project/issues/related_issues.md#add-a-linked-issue (solid implementation)
• Linear https://linear.app/docs/issue-relations (best UX)
• MS Project https://support.microsoft.com/en-gb/office/link-tasks-in-a-project-31b918ce-4b71-475c-9d6b-0ee501b4be57 (most mature capability)

ideally we could:

• define relationships as bi-directional things, i.e. "blocks", "is blocked by"
• see the relationships against an Issue
• view all relationships in a repo for filtered Issues (open, etc)
• view all relationships in a GitHub Project based on a filter

[evi-liu]

The public preview for issue dependencies is now available 🎉 !

If your organization would like to join the preview, just drop your GitHub org name in this discussion thread:
👉 https://github.com/orgs/community/discussions/165749

[evi-liu]

Hi all, good news! We now have a public preview available for marking issues as “blocked by” and “is blocking” 🎉 !

If your organization would like to join the preview, just drop your GitHub org name in this discussion thread:
👉 https://github.com/orgs/community/discussions/165749

[prossm]

Amazing! Thank you, Evi!

[Norbiros]

Yayy!

[sdepouw]

Nice progress! Hopefully more relationships are made available as well. (Azure DevOps sports a lot, including a generic, but useful "relates to").

[theoschafer]

We would love that! org name: Tetsuwan-Scientific

[evi-liu]

Hi all, I'm excited to announce that dependencies on issues are now generally available! 🎉 🥳 Give it a try!

https://github.blog/changelog/2025-08-21-dependencies-on-issues/

[sdepouw]

Congratulations on deployment! We're already using it for one of our projects (that couldn't participate in the beta), and I have some feedback:

Now that an Issue can be "blocked" (having an is:blocked feature and all), it would be nice to be able to manually mark an Issue as Blocked. The reason is, sometimes an Issue can be blocked for reasons other than "it's dependent on another Issue." It's understandable that these Issues would never automatically become unblocked (because there are no associated Issues for them), but in order to fully use this new Blocked structure, it's a necessity. The current workaround is to create "stub" Issues for these blocking points, but it really isn't ideal to have to do that, of course.

With this new relationship capability in place, we hope to see this extend to generic relationship. It doesn't need any automations, but sometimes it's good to be able to say "Isuses 1 and 2 relate to each other" generically. (Azure DevOps supports this, along with a host of other relationships.)

Hopefully we'll continue to see iteration!

[sophiexeon]

thank you! perfect timing <3

[Jakob-Unfried]

Nice!

Is there any reason why issues cant be "block by" an open PR?

Usually, if I start working on something right away, i only open a PR without a companion issue.
I would love to be able to set other issues as dependent on that new feature being merged.