Feature request: "is blocked by" link between issues

[vkennedy12]

Adding a "is blocked by" link between issues would be helpful for visualizing dependencies between issues in the Projects tools. If an issue closes, adding an automatic removal of the blocker link would be a nice feature as well.

[rileybroughten]

👋 Posing some questions for some more feedback regarding item dependencies and blocking relationships!

• Do you think of "depends on" and "blocked by" as the same thing or different? Would you want to define these separately or do they function similarly to you?
• What do you most often use dependencies for?
• Are there other automatic behaviors you would expect to occur between your dependent/blocking items, other than the removal of a link you mentioned above?
  • How strict or rigid would you expect these to behave, and how much would you want to be able to define yourself vs default behavior?

Curious to hear more thoughts on this 😁

[justyn]

Do you think of "depends on" and "blocked by" as the same thing or different? Would you want to define these separately or do they function similarly to you?

For me, the same.

What do you most often use dependencies for?

• Filtering: showing my assigned tasks that are not blocked
• Filtering: showing tasks that are blocked in order to see where problems might crop up
• Filtering: showing blockers, these can be quite productive to deal with since doing so will unblock other tasks
• Specific task information: when looking at a task, I want to see immediately all the other things that must be done before it can be started
• Time planning: showing a graphical representation of all that needs to be done linking one task to the next

[danpalmer]

@rileybroughten not the original poster, but just my thoughts after I found this after googling for whether this is already a feature or not...

• I think "depends on" and "blocked by" are the same thing.
• I use dependencies for two things:
  • Cutting down mental overhead by filtering out blocked tasks until they are ready¹ – this is the benefit I feel most strongly about, I find this sort of thing very valuable when I do it in other places.
  • Knowing what is higher priority to work on, based on what further work it might unblock
• For automated behaviours...
  • I would expect blocked items to be filtered out in various places/searches/lists, either by default or easily – e.g. my assigned tasks probably shouldn't include blocked ones, or at least I would want to switch to that view in most cases.
  • A dependent task being completed should nullify the effect of the link, i.e. the task is now unblocked, but keeping the link visible for historical context is useful.
  • I'd expect search to have a tag for this, like blocked-by: #<id>, potentially even showing transitively blocked tasks.
  • Being notified when an assigned issue has become unblocked, in the same way as when assigned to a regular issue perhaps.
• As for strictness, I'd probably advocate for a loose approach, i.e. you can close/complete a blocked issue, but perhaps highlight in the UI, require confirmation, something like that. Just a thought though, I don't feel strongly about that.

Footnotes

1. GTD encourages this sort of thing, including with days/times and items only arriving in you todo list at the right time. ↩

[davidpcaldwell]

People interested in this may want to upvote https://github.com/orgs/community/discussions/4928, which is related / the same.

[JonB451]

Thanks for raising this @vkennedy12

Is there a reason that no one seems to mention DAG visualizations of task dependencies, or even a DAG interface? That is what we are really looking for.

[MiYanni]

I'd extend this concept to pull requests also. My team is connected between many repos and other teams. Often, we have PRs blocked by other PRs that "flow" from other places into our repo. Therefore, when people fix issues on those PRs, it allows another PR to build properly. It would be nice to mark PRs as being "blocked" or "dependent upon" other PRs as that would help manage our required changes better.

[EmilyRosina]

My team is not necessarily after a visualisation, as mentioned here, instead we'd love some transparency detailing the blocker/blocked status and linked issues/PRs of each issue and PR. It'd be cool to have on base level of all issues and PRs, but we'd settle for a project field (at least as a starting point, and automating sync between projects if necessary).

For the most part, it's important that these relationships are easily updatable. Something similar to how tasklists would certainly work, as their tracked-by/tracking fields seem almost the same.. just for a different purpose.. and blockage is more important/helpful than tasks completed info.

Maybe a section in the sidebar or at the top, near the title could be cool?

[MiYanni]

Here's a good example for PRs:

This PR in dotnet/sdk is waiting on...

This other PR in dotnet/sdk is waiting on...

This PR in dotnet/windowsdesktop is waiting on...

This PR in dotnet/wpf which recently got merged.

[andrew222651]

You can get some of this functionality through GitHub Actions: https://github.com/marketplace/actions/blocking-issues

[dallenbaldwin]

We used to have a block in our issue description for a Waiting On section, which would include a # link to a blocking issue. We soon realized that this information is pretty hard to quickly see in most views.

We are now using a text custom field, which quickly shows up, but isn't linkable.

I suggest adding a "link" custom field type, which lets you create a # link the same way you would in the issue description. The best part is this can work for blocking dependencies or any other arbitrary link that needs a label.

when displayed in views, it would decorate and function as a link, the same way it works in the issue description

[glennsc]

Dependencies seems to be on the roadmap: github/roadmap#956

And in the SubIssues beta one of the screenshots shows some Blocked By metadata but I'm not aware of any beta on dependencies that is live yet: https://github.com/orgs/community/discussions/131957#discussioncomment-10232957

[glennsc]

I notice that the screenshots have been updated and you can’t see the Blocked By metadata anymore.

But still on the roadmap!

@rileybroughten Anything you can tell us about github/roadmap#956?

[dequejenn]

@rileybroughten - any update on why github/roadmap#956 has been closed as not doing? The issue it refers to as "updated" (github/roadmap#1036) says nothing about dependencies and blockers. Does this mean it is no longer on the roadmap? We really want to stay with github projects but this is a dealbreaker for us. If I can at least get an ETA I can probably buy some time.

[rileybroughten]

Here is the updated roadmap issue!

[ghost]

This would be great. Now I have to manually create labels for this and then inside the description of issues I mention the "blocks". But it's kind of bad

[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

[omermecitoglu]

Hello thanks for this new feature. It looks very promising. But could you tell me if is it possible to filter out "blocked" issues only by issues that are not done/closed?

I'm using this filter settings in our project view

-start-date:>@today -has:blocked-by

but when a blocker issue is closed/done, it's still a has:blocked-by situation for the other issues.

[dchristofi]

When is this feature expected to be released to GHES?

[jack66james]

That’s a really good idea. Having an “is blocked by” link would make it much easier to track dependencies and see how issues are connected. The automatic removal when the blocking issue closes would also keep things clean and organized.