Jira：“亲戚”与“有关”
在 Jira 中，将项目链接在一起既简单又有用。
例如，您可以轻松克隆问题：创建问题 100，将其克隆到 101。100 然后显示“此问题有一个克隆：101”，101 然后显示“此问题是一个克隆：100”
同样，您可以标记问题201 是 200 的重复（反向是 200 被 201 重复），还有一些其他链接类型。
我的问题是关于相关门票的使用。关系的一侧标记为“此问题与...相关”，另一侧标记为“此问题与...相关”。
您的开发团队如何定义这两个项目？除了显示不同之外，这并不重要，使链接类型略有不同，并且当一个问题是其他一些问题的“亲戚”，但也与其他一些问题“相关”时，它们看起来就像是不同的。 ...
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....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在 JIRA 中，链接是有向的，即不对称。链接的一部分是“源”，具有一个角色，例如“重复项”，另一部分是“目标”，具有另一种角色 - “是...的重复项”。
当你有一个对称的链接语义时，就像彼此相关的问题一样，这并不能很好地工作。您可以同等地命名这两个角色（“与……相关”——“与……相关”），这在某种程度上会起作用。例如，您可以预期“与……相关”会在您选择链接类型时出现两次。
在您的 JIRA 配置中，这可能会导致管理员以不同的方式定义“相关”链接类型的角色。但我想这更多的是一个错误而不是一个功能，你可以安全地忽略相同关系的两个名称之间的差异。
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.
我们实现的链接的一个示例是
功能 <-- 描述 -->史诗<--细节-->故事
功能请求是在版本中计划的内容。
许多高级史诗都描述了该功能。
故事用于提供这些史诗的细节。故事
是 'INVEST'
链接关系是
描述
详细信息
中详细描述 绘制实体关系模型并命名关系对于开发实体关系模型有很大帮助问题链接定义。
弗朗西斯
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
Details
Drawing a entity relationship model and naming the relations is helping a lot to develop the issuelink definitions.
Francis
面对同样的问题，我读过 seredas 答案 和它很好地解释了定向链接与对称语义的背景（+1） - 有趣的是，尽管这种解释使我得出了在 JIRA 中实际使用的不同结论：
正如 Steve Melnikoffs 的评论正确指出的那样，它归结为如何读者解释文本，这就是我现在的做法：虽然关系具有最不具体的链接语义，在没有更具体的链接的情况下有点像所有链接，但通常有仍然有一个问题（源）触发与另一个问题（目标）的这种关系，这一事实在 JIRA UI 中可见，通过在左列中列出链接的主动参与者和在右列中列出被动参与者。
我已经根据我正在参与的几个项目检查了这个结论，现在我会确认这个印象，即尝试从这个角度应用相关使得参与的问题更容易解决为我解读一目了然。
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.
我最近在 JIRA 中遇到了类似的功能，我必须说我非常确信后面没有隐藏任何功能。我可以理解理论上需要解决两个任务之间关系的方向..但实际上它可能不那么相关，因为根据我的经验，如果您定期使用任务跟踪系统，您会开始忽略没有任何明显特征的功能效果非常快。
..我感兴趣的是 JIRA 是否有任何插件将其功能或 UI 建立在关系导向的这个属性上。
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.
这实际上取决于您和您的团队同意的解释。
在我们的 JIRA 中，我们发现默认的“relates to”标签过于模糊，因此我们修改了默认的 inward & 标签。外部标签为“涉及”和“与...相关”以区分链接方向，同时同意这些问题在本质上是相关的，只有通过逐案阅读这两个问题才能理解，并且方向仅表明链接是从哪个问题创建的，仅此而已。即使进行了这些更改，我们发现这种链接类型实际上除了根据上下文充当一种提醒之外并没有提供太多意义。最近，我们创建了几种新的问题链接类型，以更具体地指示相关问题的性质，从而更好地为我们服务。
如果您想更深入地了解 JIRA 中的问题链接和默认问题链接类型，我们有 在这里发布了一些信息。
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.