Issue Dependencies [Public Preview Feedback]

[evi-liu]

👋 We're excited to share that issue dependencies are now available in opt-in public preview! 🎉
If you'd like to try out this feature, please comment in the discussion below with your GitHub organization name.

dependencies-staff-ship.mp4

What are issue dependencies?

Issue dependencies let you define work that must be completed before other work can begin, commonly referred to as "blocked by" or "blocking."

This has consistently been one of the most requested features for planning and tracking.

What you can do with issue dependencies

Mark issues as "blocked by" or "blocking". You can mark up to 50 issues for each relationship.

See blocked issues on the issues index page:

View blocked issues directly within your project:

Search for issues in projects or on the issues index page:

What we are thinking about next

📣 API and webhook support
We want to make sure dependencies are fully supported via our public interfaces. It’s not done until there’s an API!

🕒 Issue timeline events
Dependencies will show up in the issue timeline, so you can track when they were added or resolved.

📊 Deeper projects integration
We're curious how you'd like dependencies to appear in projects. Would you want a dedicated column or field? The ability to group or filter by dependencies?

How you can help

We’d love your feedback! In particular, we’re interested in:

• Where else would you expect to see dependencies across GitHub?
• In projects, would a dedicated column or field for dependencies be useful? Would you want to group or filter by them?
• Are there other types of relationships between issues you’d like to set?
• On the issues index and in projects, we currently show blocked issues. How important is it to also show blocking issues?

[jkgerig]

We (Recidiviz) would like to join this public preview

[HarshAShukla]

@nasquasha @evi-liu could you please add org - Harsh-SAFe for public preview?

[nasquasha]

Added!

[dequejenn]

dequelabs!!!!! We have been waiting for this for a long time - thank you!!!!!

[kflynn]

Emissary would love to try this out, thank you!!

[DylanBulmer]

ReMo would like to use this!

[davidmarble]

Great to hear! Opt us in: DepoDirect

Just getting started with a POC of using Projects/Issues for the team, so no opinions yet about your questions.

You might get some discussion about semantic differences between using the term "block" vs "depend" (and some votes to support both terms) for this feature, even if the implementation for a system that supports one or both terms is largely the same. I think the difference is in communication clarity when working with teams. To many, "block" has a negative connotation (something unexpected happened that's blocking this, or I'm/we're blocked by some other person/team) while "depend" has a foresight connotation (this issue depends on us finishing this other work, which is all part of the plan). I'm happy with 1 way to say/do it for now.

[evi-liu]

Your org is now in the public preview! And gotcha on the nomenclature - this is something we're keeping an eye on as well.

[marionzr]

@evi-liu I agree with @davidmarble. I use "blocked" and "depend" with different purposes, especially when applying Critical Path Method (CPM) for project planning. In this context, these terms help distinguish between different types of task relationships that can impact the project timeline.

Blocked by: For me, this indicates a Finish-to-Start (FS) dependency, where Task-2 cannot even begin until Task-1 is completed. In other words, Task-2 is directly blocked from starting because it is waiting on Task-1 to finish.

Depends on: On the other hand, "depends on" typically refers to a Finish-to-Finish (FF) or Start-to-Finish (SF) relationship. In this case, I can start Task-3, but I cannot finish it until Task-1 is completed. Task-3 is "dependent" on Task-1 for completion, though not necessarily for starting.

These distinctions are important in Critical Path Analysis, where the flow of tasks and their dependencies can directly influence the project's overall timeline. The "blocked by" relationship indicates a strict bottleneck that prevents starting a task, while "depends on" suggests that work on a task can progress, but its completion is contingent on another task finishing.

[marionzr]

In addition to "blocked by" and "depends on," there are other useful links for project management in Agile development:

Relates to: Tasks that are related but not dependent on each other, similar to a Start-to-Start (SS) dependency where work can happen concurrently but independently.

Duplicates: Tasks addressing the same issue. This avoids redundant work and helps with backlog prioritization. It’s akin to resolving duplicate dependencies, ensuring teams focus on unique tasks.

Clones: Tracks recurring tasks or bugs. This resembles a Finish-to-Finish (FF) dependency, where multiple tasks may be finished at the same time or follow similar patterns for resolution. This is also helpful for bug tracking and managing technical debt, ensuring similar issues are addressed systematically

[Julian-Dumitrascu]

Relates to

This is no type of relation. Other developers let us create types of relations. They can do even more for us.

[oliverklee]

We'd like to join:

• mbt-ostermann
• braingourmets
• MyIntervals

[evi-liu]

Your organizations have now been added to the public preview!

[jarpoole]

My org would love to try: ScriptionAI

[evi-liu]

Your org is now in the public preview!

[grafana-dee]

Please enable for https://github.com/grafana :)

[evi-liu]

Your org is now in the public preview!

[mmaetzler]

We would love to join: https://github.com/tesseracthealth

[evi-liu]

Your org is now in the public preview!

[shalauko]

Please add us as well
https://github.com/needcodeio

[evi-liu]

Your org is now in the public preview!

[shalauko]

Thank you for this feature. I think it is one of the most wanted feature in GitHub Projects and finally we have it!
So far it works as I would expect.

The one feature what I'm missing is a visualization of the dependencies in a graph-like style. I used to use it in JIRA and I think it is very convenient.

It would be nice to see arrows on Roadmap view. Potentially it may be also usable on Kanban view. If arrows have colors it would be even better. Something simple like the following convention.

Assumption: issue_b is blocked by issue_a.

On the Roadmap view I would like to see an arrow pointing from issue_a to issue_b. Then:

• the arrow is green if target date of issue_a is before start date of issue_b
• the arrow is yellow if target date of issue_a is after start date of issue_b, but before target date of issue_b
• the arrow is red if target date of issue_a is after target date of issue_b

Here is an example how it looks in the JIRA.

[Norbiros]

Please add:

• https://github.com/CrabCraftDev
• https://github.com/Hack4Krak
• https://github.com/Zorya-Dev

[evi-liu]

Your orgs are now in the public preview!

[prossm]

https://github.com/idealist7

[evi-liu]

Your org is now in the public preview!

[maliberty]

Please add https://github.com/The-OpenROAD-Project

[evi-liu]

Your org is now in the public preview!

[lberrymage]

We would like to join: https://github.com/accrescent.

[evi-liu]

Your org is now in the public preview!

[ptsouchlos]

We would like to join: @xstrahl

[evi-liu]

Your org is now in the public preview!

[ptsouchlos]

Thank you!

[agilesteel]

We would like to join https://github.com/formslogic

[evi-liu]

Your org is now in the public preview

[ghost]

We would like to join https://github.com/userh-dev

[evi-liu]

Your org is now in the public preview

[acidoxee]

We'd like to join please! @seyna-insurance

[evi-liu]

Your org is now in the public preview!

[RussTedrake]

I'd love to opt-in with https://github.com/RobotLocomotion/, please.

[minhho-itr]

We'd love to join, please add: https://github.com/ITR-vietnam

[tats-u]

Every organization can try this feature today, can't it?

@evi-liu Could you remove or modify the following descriptions?

👋 We're excited to share that issue dependencies are now available in opt-in public preview! 🎉
If you'd like to try out this feature, please comment in the discussion below with your GitHub organization name.

[nwalters512]

Are there plans to support this for pull requests? We currently track blocking/blocked-by relationships with things like a "blocking" label and text like "Blocking #NUMBER" in the PR description. It'd be great to have platform-level support for this!

[stherold]

Workaround: We have the rule to back each PR by an issue. This can then be used with all GH Issues features.

[Blackjacx]

Hey ✌️ not sure if it has been posted already, but what I'd love to see are the following things:

1. A similar UI to the parent/child relationship on the project board, i.e. a progress bar that shows how many issues are still blocking an issue. This could be a field on the board so it can be shown/hidden.
2. Option to filter project board by the number of blocking issues, e.g. blocked-by==0. This is super useful to find ready-to implement issues.
3. What would be really cool is the option to show a dependency graph for a project. It should visualize the dependency hierarchy in a project. The main purpose is to easily identify the blocking issues that have to be solved first.
4. Maybe some markdown support to render the blocking/blocked-by issues list in the description of the issue by using a placeholder, i.e. ![blocked-by], ![blocking-by]. Useful for epics or grouping issues that just want to show the subtasks (blocking issues) in the description.

[jvsandick]

We'd love to join
https://github.com/splendo

[dennyabrain]

https://github.com/tattle-made/ would like to join :)

[piquet-h]

There's a bug in the REST API. (I've logged a ticket)

In one of my repos, If I try a gh request to add a blocked issue (408) blocked by issue (403), it responds NOT FOUND.... but then adds a blocking relationship to an issue in an external repository belonging to somebody else.

[hannahhoward]

Can we join in for organization github.com/storacha ?

[fnesveda]

Hi, can we join with our GitHub orgs, please? 🙂

• https://github.com/apify
• https://github.com/apify-store
• https://github.com/apify-projects

[chase-roohms]

Hi @evi-liu can I join this public preview with transmute-app please?

https://github.com/transmute-app

[neutrinoceros]

We (astropy) would like to opt into this public preview. Thanks !

[beerinho]

Does anyone know if this will be coming to pull requests? I'd love to see it there

[Nickcom4]

The public-preview issue dependencies are great, thank you. One gap stops us
using them in Projects: Blocked by / Blocking aren't available as Project
table fields (columns).

Parent issue and Sub-issues progress are already native Project fields with
live links. Please expose Blocked by and Blocking the same way: read-only
relationship columns that show the linked issues as live links, with their
open/closed state.

Today the only way to see dependencies on a Project board is to copy them into
a plain-text custom field via the API on a schedule. That loses the links and
has to be re-synced constantly. A native field removes that entirely.

Two things that would make it complete:

1. Live links to the related issues, like Parent issue.
2. Auto-clear the relationship from the view when the blocking issue closes,
   so the board stays clean.

This would let us filter and group by "is blocked" and spot bottlenecks
natively.

[thorntonryan]

I'll echo similar sentiments, our organization would welcome a blocked-issue progress field in the Project Table view.

For example, suppose we wanted to migrate our apps to a major version of a library (e.g. Qt6).

The steps we'll take:

• Migrate app to x64
• Address outstanding deprecations in Qt5.x
• Update to Qt6
  • sub-issues, etc.

Migrating to x64 and addressing deprecations are rather orthogonal to the main task (Qt6), but we'd still like to show progress towards that over-arching goal without needing to create yet another top level issue to encapsulate the sequential steps.

Using the "blocked-by" relationship seems appropriate. Blocked by orthogonal work that wants to get something to a better stopping point before making a formal cutover.