ZenHub’s Issue dependencies not only help teams visualize relationships between pieces of work, but they save team members a lot of time that would otherwise be lost just hunting down information.

When relying on just a list of GitHub issues and comment references to other Issues, there’s a strong possibility that visibility into how these changes impact other tasks get lost or forgotten.

Tracking dependent relationships between Issues and whether something is blocking another piece of work is important with any project process because it creates a central hub where everyone can communicate what’s needed without relying solely on meetings or comments to uncover important connections.

It's also common to want to compute the transitive closure of these relations, for instance, in listing all the issues that are, transitively, duped to the current one to hunt for information about how to reproduce them.

The "meaning" will tell Gitlab how to interpret the relation. For example, a "parent/child" relation will have the meaning set to "one is a part of another", and then user may define a "subtask" and "subcomponent" relations to distinguish two situations, but Gitlab will understand because all three will have the same meaning and it can render a tree with three different kinds of edges.

Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.

This would be transformational in the scope of what issues can be effectively used for!

Blockers would give better insight into when an issue can be started,

Our flow is: The reporter reports an issue, and we developers create sub tasks upon that issue... in Redmine, we also had a percentage graph that would reach 100% when all sub-tasks were completed, was a great way about checking 1 item without the need to drill down all subtasks.

We use GitLab to manage software on interconnected embedded systems. What often comes up is this: New functionality on one system changes the protocol in a slightly incompatible way. Software on other systems have to be updated to understand the new protocol, take advantage of the new functionality, and stop complaining about the unexpected data. For this I would create multiple issues: Issues for the new functionality that we need. (Project A) Issue for defining the protocol changes. (Project A) Issue for implementing the protocol changes on the module. (Project A) Issues in related software projects for implementing the changes required to understand the new protocol. (Project B, C, D...)

bugzilla has had the concept of one or more ticket(s) blocking another for quite some time. We used that for over ten years before switching to GitLab and it is a feature I miss. A dependency tree between issues enables planning and workflow. This is can be seen as related to issues boards in that blocked issues should not be able to move ahead until the blockers are at least implemented perhaps reviewed.

It would be useful filter to have, also it would be useful to sort issues using topological order on Board and other issue listings, so the unblocked issues would be first.

Simple relations: [Issue A]---(relation R)--->[Issue B], which is a ternary (A, B, R) relation in a database.

I see specific relations in a similar way as labels. If a "label" is a binary relation between a label and an issue, "relation" between issues would be ternary relation between two issues and a label (from different set than ordinary labels).

One of the reasons that some projects don't use Gitlab's issues and use an external tracking platform is the lack of issues relations. Without relations issues are just flat, no way to actually track progress of big features. No way to create a "meta" issue that depends on 4 other or create subtasks and so on. The same problem exists on Github too. It would surely make a difference if Gitlab offers a full features tracking issue, instead of just flat issues. Relations is a major first step towards that.