Этикет отслеживания ошибок - некромантия или дубликат?

Я обнаружил очень старую (более 2 лет) проблему с запросом на функцию в трекере ошибок для проекта с открытым исходным кодом, которая была помечена как «решена (не будет исправлена)» из-за отсутствия инструментов, необходимых для выполнения запрошенного улучшения. За время, прошедшее с момента принятия этого решения, были разработаны новые инструменты, которые позволят решить его, и я хотел бы довести это до сведения сообщества для этого приложения.

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

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

Я бы порекомендовал снова открыть старую и добавить в нее новую информацию. С точки зрения измерений / метрик, это, вероятно, было бы наименее вредно - новая вещь - это не новый дефект или улучшение, а скорее пересмотр старого. Должно быть какое-то состояние для входящих запросов на изменение, которое указывает, что оно должно быть рассмотрено ответственным лицом. Изменяя состояние обратно на это, они могут видеть историю (факт, что она была однажды отложена ранее), а также новую информацию легко.

Я бы сделал (и делал в прошлом) создание новой ошибки (чтобы придать ей актуальность), запомнил возможное / новое исправление и ссылку на старую для исторической ссылки / отслеживания.

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

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

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

С моей точки зрения, некромантия меньше зла. Если некромантия - это проблема, мы должны бороться с чем-то, что вызывает проблему, а не с самой некромантией (если вы нашли какую-то новую информацию о старой ошибке, что с этим не так? Это совершенно естественно). Например, если кто-то оставит комментарий к старой закрытой ошибке, это должно каким-то образом привлечь внимание всех заинтересованных пользователей.

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

Вы должны точно знать, почему было решено не исправить в первую очередь.

Я бы сказал, что это отличается от ошибки и запроса функции.

Когда вы создаете отчет об ошибке в bugtracker, вы обычно описываете симптомы. Это, однако, не означает, что основная причина та же или даже похожая. Особенно, если внутренние компоненты хорошо скрыты от конечного пользователя, и все, что вы получаете, это общая ошибка, когда что-то пошло не так. В таких случаях некромантия - это не тот путь, поскольку, хотя внешние симптомы могут показаться схожими, скорее всего, это совершенно другая ошибка. Если вы снова откроете старую ошибку, разработчик, вероятно, начнет исследовать старую причину, которая может привести его в совершенно неправильное русло и потерять время.

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