Джира: "Родственник" против "Родственный"

Question

В Jira объединять элементы легко и полезно.

Например, вы можете легко клонировать проблему: создайте проблему 100, клонируйте ее в 101. 100 затем показывает «эта проблема имеет клон: 101», а 101 затем показывает «эта проблема является клоном: 100»

Аналогично, вы можете пометить выпуск 201 как дубликат 200 (обратное значение 200 дублируется к 201), и есть несколько других типов ссылок.

Мой вопрос касается использования связанных билетов. Одна сторона отношения помечена как «Эта проблема связана с ...», а другая сторона говорит: «Эта проблема относится к ...».

Как ваша команда разработчиков определяет эти два элемента? Это не имело бы большого значения, за исключением того, что дисплей отличается, делая типы ссылок немного отличающимися, и это просто выглядит так, как будто они отличаются, когда одна проблема является «родственницей» нескольких других проблем, но также «связана» с некоторыми другими. ...

Answer 1

В JIRA ссылки направлены, т.е. не симметрично. Одна часть ссылки - это «источник» с одной ролью, например «дубликаты», другая - «цель» с другой ролью - «дубликат».

Если у вас есть симметричная семантика ссылок, например проблемы, связанные друг с другом, это просто не работает. Вы можете назвать обе роли одинаково («связано с» - «связано с»), и это будет работать в некоторой степени. Вы можете ожидать, что «относится к» появится дважды, когда вы выбираете тип ссылки, например.

В вашей конфигурации JIRA это, вероятно, приводит к тому, что администраторы по-разному определяют роли для "связанного" типа ссылки. Но я думаю, что это скорее ошибка, чем функция, и вы можете спокойно игнорировать различия между двумя именами одного и того же отношения.

Answer 2

Столкнувшись с тем же вопросом, который я прочитал ответ seredas , и он прекрасно объясняет фон направленных ссылок и симметричную семантику (+1) - интересно, хотя это объяснение привело меня к другому выводу практическое использование в JIRA:

Как правильно сказал комментарий Стива Мельникова, все сводится к тому, как читатель интерпретирует текст , вот как я делаю сейчас: в то время как Отношение имеет наименее конкретную семантику ссылки, вид перехвата всей ссылки при отсутствии более конкретной, обычно есть еще одна проблема (источник), вызывающая эту связь с другой (целью), и этот факт можно увидеть в пользовательском интерфейсе JIRA, перечислив активных участников ссылки в левом столбце и пассивных в правом.

Я проверил этот вывод по нескольким проектам, в которых я участвую, и сейчас подтвердил бы это впечатление, то есть попытка применить относится к с этой точки зрения, немного усложняет проблемы участия мне проще с первого взгляда.

Answer 3

Пример ссылки, которую мы реализовали:

Функция <- описывает -> Эпический <- подробности -> История

Запрос функции - это то, что запланировано в выпуске. Особенность описана рядом эпопей высокого уровня. Истории используются, чтобы предоставить детали этих эпопей. Рассказы «ИНВЕСТ»

Отношения ссылки

Описание

• x 'описывается как' y
• у 'описывает' х

Подробнее

• x 'подробно описано в' y
• y 'детали' x

Создание модели отношений сущностей и присвоение имен отношениям очень помогают в разработке определений Isselink.

Фрэнсис

Answer 4

Это действительно зависит от интерпретации, с которой вы и ваши команды согласны.

В нашей JIRA мы обнаружили, что метки по умолчанию «относится к» являются слишком неоднозначными, поэтому мы изменили стандартные метки «внутрь» и «наружу», чтобы они читались как «относится к» и «относится к», чтобы различать направление ссылки, соглашаясь, Проблемы связаны по своей природе, что можно понять, только прочитав обе проблемы в каждом конкретном случае, и что направление указывает только на то, из какой проблемы была создана ссылка, и больше ничего не значит. Даже с этими изменениями мы обнаружили, что этот тип ссылки на самом деле не имеет большого значения, кроме того, что служит своего рода напоминанием в зависимости от контекста. Недавно мы создали несколько новых типов ссылок на проблемы, чтобы более конкретно указать характер связанных с ними проблем, которые нам / намного / лучше помогают.

Если вы хотите глубже погрузиться в ссылки на проблемы и типы ссылок по умолчанию в JIRA, мы опубликовали некоторую информацию здесь .

Answer 5

В последнее время я сталкивался с подобной функцией в JIRA, и должен сказать, что был почти уверен, что за ней нет скрытой функции. Я могу понять необходимость рассмотрения ориентации отношения между двумя задачами теоретически ... но практически это может быть не так важно, потому что из моего опыта, если вы регулярно работаете с системой отслеживания задач, вы начинаете игнорировать функции без каких-либо заметных эффект очень быстро.

.. меня интересует, есть ли какой-нибудь плагин для JIRA, который основывает свою функциональность или пользовательский интерфейс на этом атрибуте ориентации отношений.