Jira: “Relative of” vs “Related to”

Question

In Jira, linking items together is easy and useful.

For example, you can clone an issue easily: Create issue 100, clone it to 101. 100 then shows "this issue has a clone: 101" and 101 then shows "this issue is a clone: 100"

Similarly, you can mark issue 201 as being duplicate of 200 (reverse is 200 is duplicated by 201), and there are a few other link types.

My question is around the use of related tickets. One side of the relationship is marked "This issue is related to ..." and the other side says "This issue is a relative of ...".

How does your dev team define those two items? It wouldn't matter much except the display is different, making the link types slightly different and it just looks like they are different when one issue is "a relative of" a few other issues, but also is "related to" some others....

Answer 1

In JIRA, links are directed, i.e. not symmetrical. One part of the link is the "source", with one role, like "duplicates", the other is the "target" with another role - "is duplicate of".

When you have a symmetrical link semantics, like issues related to each other, this just does not work well. You can name both roles equally ("is related to" -- "is related to"), and this will work to some extent. You can expect "is related to" appear twice where you select a link type, for example.

In your JIRA configration, this probably lead administrators to define the roles for the "related" link type differently. But I guess this is more a bug than a feature, and you can safely ignore the differences between two names of the same relationship.

Answer 2

An example of link that we implemented is

Feature <-- describes --> Epic <-- details --> Story

A feature request is something that gets planned in a release. The feature is described by a number of high level epics. Stories are used to provide the details of these epics. Stories are 'INVEST'

The link relationships are

Describes

• x 'is described by' y
• y 'describes' x

Details

• x 'is detailed in' y
• y 'details' x

Drawing a entity relationship model and naming the relations is helping a lot to develop the issuelink definitions.

Francis

Answer 3

Facing the very same question I've read seredas answer and it is explaining the background of directed links vs. symmetrical semantics nicely (+1) - interestingly though this explanation led me to a different conclusion for practical use in JIRA:

As Steve Melnikoffs comment correctly puts it, it comes down to how the reader interprets the text, here is how I do now: while Relation has the least specific link semantic, kind of a catch all link in absence of a more specific one, there is usually still one issue (the source) triggering this relation to another one (the target), and this fact is visible in the JIRA UI by listing the the active participants of a link in the left column and the passive ones in the right one.

I've checked this conclusion against a couple of projects I'm participating in, and I'd confirm this impression now, i.e. trying to apply relates to from that angle makes the participating issues a bit easier to interpret for me at a glance.

Answer 4

I have encountered similar feature in JIRA lately and I must say I was pretty much convinced that there's no feature hidden behind. I can understand the need of addressing the orientation of the relation between two task theoretically .. but practically it might not be that relevant because from my experience if you work with task tracking system on regular basis, you begin to ignore the features without any noticable effect very quickly.

.. what interests me is whether there's any plugin for JIRA that bases its functionality or UI on this attribute of relation orientation.

Answer 5

It really depends on the interpretation you and your teams agree upon.

In our JIRA we found the default "relates to" labels to be too ambiguous, so we modified the default inward & outward labels to read "relates to" and "is related to" to distinguish link direction, while agreeing that the issues are related in a nature that can only be understood by reading both issues on a case-by-case basis, and that the direction only indicates from which issue the link was created and means nothing more. Even with these changes, we have found that this link type doesn't actually provide much meaning beyond serving as a sort of reminder depending on context. Recently we created several new issue link types to more concretely indicate the nature of related issues, serving us /much/ better.

If you want to dive a little deeper into issue links and the default issue link types in JIRA, we have published some info here.