Support issue dependencies

[garfieldnate]

Allow the creation of dependencies between issues, e.g. issue 3 requires the completion of issue 1 before work on it can begin, etc. I often find myself hesitant to submit any issues that can't be fulfilled for a long time because I don't have a direct way of tracking dependencies. I think that this feature would make it easier to manage projects here.

Currently dependencies like this can be done by making a separate milestone for each issue with dependencies and adding the relevant issues to that, but that is clumsy.

Basic functionality would just be the display of dependencies or reverse dependencies on an issue page, but the ability to make a graph of some kind would be quite nice.

[captn3m0]

I think this would create an unnecessary complication, and make the interface much more complex. Zach once gave an example of a Redmine issue creation page vs GitHub's in one of his talks:

vs

From the talk http://zachholman.com/talk/how-github-uses-github-to-build-github/

[garfieldnate]

Hmm, yes I think they were going for minimalistic and it is very easy to look at compared with the alternative. Perhaps this would be better done by another tool through the GitHub API.
Then again, if it were simply parsed out of the description then it would not complicate the UI.
"depends on: ..."

[Mithgol]

I guess you could do it with the current GitHub already. Just write “depends on: …” and then visit all the dependencies and mention your new issue. The mentions are then become displayed on that new issue's page, including the status (open, closed, proposed, merged) of each. I know this trick isn't automated, but for a couple of dependencies even doing it manually won't hurt too much.

[mhulse]

I guess you could do it with the current GitHub already. Just write “depends on: …” and then visit all the dependencies and mention your new issue.

Sometimes I'll create a "master" checklist issue that points to all the dependent issues. Example:

• Support issue dependencies (Support issue dependencies #210)
  • Allow the creation of dependencies between issues, e.g. issue 3 requires the completion of issue 1 before work on it can begin, etc.
• ....

The above, in combination with milestones, works pretty good.

Having just tested, as I haven't tried this before, milestones work with checklists too:

[bartlettroscoe]

Just like Trac, it would be nice if a project could decide if it wanted to augment basic GitHub Issues to support more features like dependency tracking. That way, you can have your cake and eat it too (or take as much cake as you want and eat as much as you want).

For interactions with open-source users, the simplicity of GitHub Issues is great. But for serious project tracking, GitHub Issues are majorly lacking.

[aspiers]

I think this would create an unnecessary complication, and make the interface much more complex.

Sorry, but this "dumb everything down" attitude really annoys me, because it makes the patronising assumption that I'm not capable of dealing with the increased complexity (which, let's face it, would be very small in this case) and as a result I'm left with a crippled tool which doesn't properly support my development workflows. If you really believe that minimalism and simplicity should trump functionality then I suggest you go and buy a MacBook Wheel.

[ggeorgiev]

A lot of smart people say: "Everything should be made as simple as possible".
The geniuses say: “Everything should be made as simple as possible, but no simpler.”

Lacking basic important functionality is not simple - it is simpler.

[vphantom]

My main use for dependencies is to get a clear TODO: I want a way to see issues which don't depend on any other open one, so I can easily focus on leaves and work my way up the tree. Having everything at the same level doesn't scale very well.

[ghost]

I'm not even a programmer, just a UX dude and project manager and I want to have issue dependencies (as well has being able to group several issues into epics or having sub-issues). Simplicity should increase efficiency not impair it.

[kaspar030]

Our project (>150 contributors) is quite spread over the world, and all but the simplest PRs/issues have some dependencies. Currently we're using "Depends in X" or "Needed by Y" in the comments or description, but that is usually out of date and doesn't scale.

There's a bunch of external tools (codetree, zenhub) which offer this feature, and IMO it is the main selling point of those. Unfortunately, apart from requesting full access to all your public and private repositories, they're another site, another interface, ... and not free.

Having this integrated into github would be awesome.

[ad-m]

I do not understand why this change can not be made. If too complex the interface - you can make the functionality optional. Just as you can disable "Issues", "Wiki", "Projects" at both organization level and individual repositories. The same can be done with "Dependency tracking".

[ad-m]

Is there any bot to emulate that by comment commands?

[markcellus]

I do not understand the impatience around this request. It seems that this request is essentially asking Github to be a project management tool like JIRA. Dependency management of issues is not as easy as everyone makes it seem in this thread.

Adding dependency chains to any system requires more than just adding a "link a dependency" button to Github issues and a few new checkboxes to the settings page. It needs to support nested dependency trees, changing and rearranging of dependencies, handling possible circular dependencies, resolving broken dependency chains, etc

Doing a feature like this is less about "complicating the UI" and more about making sure that it is full-fledged enough to actually be useful. But at that point, aren't we just turning Github into JIRA?

[aspiers]

I do not understand the impatience around this request.

Maybe you don't need dependency management as much as other people. That's totally fine. It doesn't make their need any lesser, however :-)

It seems that this request is essentially asking Github to be a project management tool like JIRA.

No, I think you really misunderstood this request - it's nothing like that. Let's recall the original request:

Basic functionality would just be the display of dependencies or reverse dependencies on an issue page, but the ability to make a graph of some kind would be quite nice.

That is light years away from a description of JIRA.

Dependency management of issues is not as easy as everyone makes it seem in this thread.

Sorry, but I disagree.

Adding dependency chains to any system requires more than just adding a "link a dependency" button to Github issues and a few new checkboxes to the settings page. It needs to support nested dependency trees, changing and rearranging of dependencies, handling possible circular dependencies, resolving broken dependency chains, etc

No it doesn't. Sure, those things would be nice, but they can come later (if ever) - there's no reason why this couldn't be developed incrementally, one sensibly small step at a time. That's how all decent software is built.

Doing a feature like this is less about "complicating the UI" and more about making sure that it is full-fledged enough to actually be useful.

I disagree. It would be useful even if all it did was model bi-directional links between issues. Any subsequent sophistication added would incrementally increase the usefulness.

But at that point, aren't we just turning Github into JIRA?

No. JIRA is a completely different beast. (And even if it developed more features similar to JIRA, that wouldn't necessarily be a bad thing.)

In summary: please don't throw the baby out with the bathwater.

[markcellus]

Please do not put words in my mouth. I am not saying the feature isn't needed and shouldn't be implemented, so I am not throwing any baby out of water. What I am saying though is that this type of feature takes a while to get started on so it's good to be patient.

Obviously, you and I disagree on quite a bit, because I totally disagree with most of what you said. You are right in the sense that every piece of software needs to start somewhere, but planning for scalability must come first. Refusing to do this is exactly how bad software starts. You cannot just write code and push things into production without a good foundational plan and prioritization for that code.

[aspiers]

I am not saying the feature isn't needed

Sorry if I got the wrong impression, but that's what it sounded like when you said "I do not understand the impatience around this request." If the feature is needed, why wouldn't some (even if not necessarily many) people be impatient for it? I'm sure I'm not the only one who noticed this deficiency in GitHub's issue tracker several years ago.

Obviously, you and I disagree on quite a bit, because I totally disagree with most of what you said. You are right in the sense that every piece of software needs to start somewhere, but planning for scalability must come first.

I agree that a certain degree of planning for scalability is worthwhile, especially at GitHub scale. But why is this mutually exclusive with just adding The Simplest Thing Which Could Possibly Work?

Refusing to do this is exactly how bad software starts.

Well there are many ways bad software can start. Lack of scalability planning can sometimes be one of them, but honestly that's such a generaIization that without context it's not a particularly useful statement. But anyway, I wasn't proposing anyone should refuse to do any planning, so I'm not sure what your point is here.

You cannot just write code and push things into production without a good foundational plan and prioritization for that code.

Again that's another very generalized statement which I could end up strongly agreeing or disagreeing with, entirely depending on the context. I could risk an assumption that you're less of a fan of agile software development than I am, and if my assumption was correct we could agree to disagree on that basis. But I think this is already a big tangent and this GitHub issue is not the right place for that discussion.

[TPS]

@aspiers @mkay581 I hate to complain, folks, but unless either/both of you work for the appropriate team @github, y'all do realize this discussion is pointless & unnecessarily spams the issue for those of us actually waiting for an update about what @github is doing to implement.

I do realize the irony that @aspiers mentions below, but it seemed prudent to try to head off a full flamewar.

I will now be blocking both of y'all.

[aspiers]

y'all do realize this discussion is pointless

Of course I do, that's why I already said the following in order to stop the tangent:

But I think this is already a big tangent and this GitHub issue is not the right place for that discussion.

The irony is that despite complaining about spam, you just added to the spam with your own comment which required me to defend mine with another off-topic comment. However this will be my last off-topic comment on this issue, regardless of any potential future attacks.

I will now be blocking both of y'all.

Your loss not mine.

[hlindberg]

I would also like to have simple handling of dependencies. There is already one kind of dependency at github; "referenced". Earlier comments makes it sound like some complex things are needed, but I think only a couple of simple additions are actually required:

• Being able to give a reference-kind when making a reference
• Displaying the reference-kind in the referenced issue (instead of just "referenced by other issue", it would say "referenced as reference-kind by other issue"
• When rendering the link (i.e. #n) it should be rendered with strike-through if the issue is closed - for example Show code preview in comments #123. This is important since you then do not have to follow every link to learn if it is closed or not. Many Ux alternatives here: could color it differently, and could show "closed" in the tooltip that appears when mousing over. (If doing nothing else, this small thing would be very helpful).

A next step would be to do a little more and make different kind of references have bi-directional semantics. For instance if an issue is "blocked by" another, then the relationship in the other direction is 'blocks'. The currently relationship is simply "relates to" at both ends. A third relationship of value is "duplicated by"-"duplicates". I can imagine GH adding these three as the only available kinds of relationships. You would then use this by using one of the keywords in the references - for example #blocked by-24, #blocks-123, #duplicates-42 etc. The default when a relationship is not used is #relates to-. Then, in an issue, the list of references would simply be organized per relationship-kind. Since the relationship is created at one end - you can delete the entire relationship by editing the comment where the reference is made. If user enters #blocks-2 in issue 1, and #blocked by-1 in issue 2, this would create two relationships and they are both shown - user then sees that and can delete one of them - no need to pair them up or anything.

The system would not do anything with the relationships other than displaying them and allowing users to navigate them. It does not matter if users create circular links.
It would be useful to query for "all issues that have 'blocked by' references where all referenced tickets are closed" - you get them in a list, and you can update them in bulk (perhaps drop a 'blocked' label that you assigned).

[vphantom]

@hlindberg is dead-on here: relationship qualifiers would be implicitly opt-in, adhering with GitHub's goal of staying exactly as simple as it currently is for novice users. Grouping relationships by qualifier in the UI (in addition to their events in the history of the issue) is also a non-intrusive addition that novice users would be blissfully unaware of.

I was about to suggest arbitrary qualifiers (like we have for labels), but we do need "showstopper" vs "informational" classes of qualifiers, for search purposes. The key in my workflow would be to search for is:issue is:open assignee:vphantom not:blocked for example. So something like is:blocked vs not:blocked would be extremely useful in restricting results to issues which have or don't have any open blocking relationships. Like the other proposed changes, this is merely an addition to available advanced search criteria and wouldn't negatively impact the experience of novice users.

[vancouverwill]

the fact github won't allow ordering of pull requests is the main reason why I suggest to teams to use https:/phacility/phabricator as it makes dependency of tickets and ordering of when they getting deployed a lot easier and reliable that they don't get out of order.
Having an optional link to parent pull request would be big win in making GitHub more appropriate for enterprise scale software. Also as mentioned above this feature could be disabled by default if there are concerns that too complicated UI for most people.

[ldhasson]

Dependencies between issues is a real world scenario. Showing examples of poor UI to say the feature is not useful misses the point. You guys are the aces of cool simple interfaces, so can you figure it out? I am having a hard time managing dependencies between issues across repositories and that is causing us to release component-based software where sometimes, we accidentally miss such dependencies. Having it documented is of course something we do, but a hard check that would prevent from merging a pull request for X unless its dependency Y was already merged seems a very basic things.

[KevTheRev13]

+1, I would love a way to mark dependencies between issues within Github.

I came to this thread after a google search, assuming this was already a capability. I'm pretty surprised this isn't - it seems like an obvious need if you are doing some light project management in Github.

Please consider supporting this feature. Thank you.

[nathan-at-least]

+1 for @hlindberg's proposal with only "relates-to", "blocks / blocked-by", and "duplicates / duplicated-by". An orthogonal feature is to display a summary list of these links on an issue page. With the five unidirectional relationships above, that's five lists. With github's current feature set with only "relates-to" that's a single list.

Note that a key feature of @hlindberg's proposal is to retain the existing cross-linking logging feature, so that one can see for issue X if, in the past, someone added a blocked-by #Y reference, and then later that was removed.

[PTruscott]

Pretty much what @KevTheRev13 said. This is, and will always be a desired feature. Something as simple as labels appearing on the dependencies/dependees would ease a lot of issues. (ay)

[quasicomputational]

What'd be really nice is to get a notification on an issue when all of its dependencies have been closed, instead of having to check each time an issue gets closed to see what's unblocked.

Also, dependencies should be declarable cross-repository, even if the dependency is locked, etc; there doesn't need to be a backlink going from the dependency to the dependent, IMO.

[ghost]

AFAICT, @microsoft already has such project management suite @

It being Microsoft and their infallible track record regarding botching everything UX/UI so badly it hurts, I'm not touching anything from Microsoft unless I'm forced to. I've been using Office365 and it's pretty bad. I've been using MS Teams and it's horrible – so many UX/UI blunders, that thing is unusable. Outlook – worst email client I've seen in years, the list goes on…

[globalcitizen]

Come on guys, this is getting ridiculous. You can't charge enterprise rates for an issue tracker and not support dependencies. My organization will consider moving off Github entirely unless this is resolved inside of 2019.

[aspiers]

@globalcitizen If you want GitHub to notice your dissatisfaction you should contact them directly. This issue tracker is unofficial and not monitored thoroughly by GitHub staff.

[ghost]

Meanwhile...

(Just FYI: I totally agree that something like "sub-issues" is missing and is extremely important)

But meanwhile I'm using the following workaround:

1. On the editor tool bar there is a checkbox icon approximately here -------v

2. It creates an item in task list. So, I'm adding a list of dependencies in the issue description (or wherever you like) with the required issues as items in the list.

For example:

Dependencies

• Feature Request: Workflow to create branch from issue #1125 Feature Request: Workflow to create branch from issue
• Add ability to assign due dates to issues. #432 Add ability to assign due dates to issues.
• Copying repository names in the "Danger Zone" #1775 Copying repository names in the "Danger Zone"

I know it's a workaround but it's better than nothing, while we're waiting for a solution coming from the GitHub team.

I hope it helps!

[naturallymitchell]

Sync closed task references GitHub Action looks like it could help.

I think, for right now, something like that and updating the Issue Summary with references, as they happen, would help.

[voronin-de]

So... I cannot have any sort of dependency between issues? I currently have an issue, where I'd like to state, that it's being blocked by another issue, which isn't resolved yet.
Of course I could just write a comment - which is in fact, what I'll be doing so. But seeing as GitHub is pretty big, I'd have thought this simple feature, which nearly every other similar product has (at least GitLab and JIRA), is already implemented - except apparently it's not.

No big deal really, because I wouldn't use GitHub for planning and issue tracking in the first place, but it is not my decision, so I am trying to have to workaround less - which brings me back to the question (since stuff has been committed): is there such a feature and I am just too stupid to find it - or is GitHub being simpler than simple?

[jerrygreen]

@voronin-de of course it's a simple feature, pretty much as simple as any of these features:

[Levi-Lesches]

I created a solution for this, if anyone is looking for one:

https:/marketplace/actions/blocking-issues

It's real value comes when you use it to mark PRs as dependent on issues, but it can be used for issue -> issue as well. (In my project, I just get started on a PR anyway and mark it as blocked by the original issue.) Just add opened, edited to the issues trigger in the blocking-issues.yml in the link above.

Here's what it looks like:

If anyone feels a feature is missing, let me know by opening an issue on the repo. I made it for my own personal project so it might not have everything you're looking for, but I'm happy to add it.

[voronin-de]

If anyone feels a feature is missing, let me know by opening an issue on the repo. I made it for my own personal project so it might not have everything you're looking for, but I'm happy to add it.

Thank you, wow 😮 ! Aren't these actions for the Workflows one creates? I'd love to have a way of marking one issue from the issue tracker as "blocked by" or "blocking" another issue from the tracker. Would this action help me there? And - I beg your pardon already - if it does: how do I make it available in the (private) repository?

[Levi-Lesches]

Aren't these actions for the Workflows one creates?

Yep, GitHub actions can also be written in JavaScript for more advanced functionality, which is what I did here.

I'd love to have a way of marking one issue from the issue tracker as "blocked by" or "blocking" another issue from the tracker. Would this action help me there?

For issues that are blocked, it creates a comment showing all the issues that are blocking it as well as which ones are closed/still opened. It also applies a label called blocked to the issue/PR. If it's a PR, the action will fail, which means GitHub will show a big X next to the merge button and can be configured to not allow merging until all the blocking issues are closed.

Currently, there is no behavior for issues that are blocking other issues. Leave an issue on the repo if you use this action and you'd like to have it and I'll put it in there (along with any other suggestions you may have).

how do I make it available in the (private) repository?

I haven't tested it in private repositories, but I don't foresee any obvious issues. I'll test it though EDIT: Can confirm, it works on private repositories as well.

[Levi-Lesches]

Also, I would encourage everyone on this repository to try to build their own actions. GitHub actions are like IDE plugins -- the IDE can't possibly have everything, so people make the things they want and share it with others, who get to choose which plugins are best for them. Odds are GitHub is not going to adopt most of the features on this repository, simply because of the costs, implementation difficulty, or if it's not suitable for the majority of their users.

But that doesn't mean you should stop wanting them! Build them yourself, or even better, search the GitHub Marketplace for an app or an action that does what you want. In most cases, if there isn't one already there that fits your needs, you can build an action by combining other actions together. For example, Labeler and PR Linter can be combined to verify PR titles and leave a label like invalid title if it's not in your chosen format. You are the open source community -- get creative!

[dword-design]

@Levi-Lesches Looks great! I actually also want this feature and kinda manually use it by curating "Blocking" and "Blocked by" bullet lists and adding/removing "blocked" and "blocking" labels. An automatic (or semi-automatic) solution would be better. I'll have a look at your action.

What I was asking myself: Does it also work between repositories? So can an issue block an issue from another repo?

[Levi-Lesches]

Does it also work between repositories? So can an issue block an issue from another repo?

Hm, didn't think about that while implementing. The way it works is it looks for Blocked by #X, #Y, #Z and looks up those issue/PR numbers in the current repo, so no, it wouldn't work between repos. Also, more fundamentally, the bot updates when issues are closed, so it would have no way of being triggered if they're on another repo. Theoretically, I could add in cross-repo support, but then the action would have to update on a schedule instead of on an event.

Leave an issue on the bot's repo if you need this and I can take a crack at it.

[dword-design]

@Levi-Lesches Alright I'll test it soon and maybe create an issue 👍.

[dword-design]

I did some quick research and thought I might update you on other options:

• dependent-issues action looks pretty nice, it's a different approach than @Levi-Lesches by looking into comments for certain keywords. Also supports dependencies between repos. I guess pick the one that suites your use case most.
• ZenHub supports issue dependencies.
• CodeTree supports issue dependencies.