Етикет відстеження помилок - некромантизм чи дублікат?

Я натрапив на справді стару проблему (2+ роки) щодо запиту на функцію в трекері помилок для проекту з відкритим кодом, який був позначений як "вирішено (не виправить)" через відсутність інструментів, необхідних для здійснення запитуваного вдосконалення. За час, що минув з моменту прийняття цього рішення, були розроблені нові інструменти, які дозволять вирішити його, і я хотів би донести це до відома громади для цієї програми.

Однак я не впевнений, що таке загальноприйнятий етикет для відстеження помилок у таких випадках. Очевидно, якщо система прямо заявляє, що не дублюватиметься, і буде активно позначати нові елементи як дублікати (значно так, як це роблять сайти SE), то відповіді було б слідувати тому, що говорить система. Але що робити, коли система прямо не говорить про це, або новий користувач не може легко знайти місце, яке відповідає вимогам системи? Чи вважається взагалі краще помилятися на стороні дублювання чи некромантування? Чи відрізняється це залежно від того, помилка чи запит на функцію?

Єдине, що може адекватно відповісти на це - це процес вашої організації. Якщо ця ситуація не визначена, її слід визначати так, щоб вона відповідала кожному разу, коли це відбувається.

Я рекомендую повторно відкрити стару та додати до неї нову інформацію, якщо потрібно. З точки зору вимірювань / показників, це, мабуть, буде найменш шкідливим - нова річ не є новим дефектом чи удосконаленням, а скоріше переглядом старої. Потрібно мати певний стан для вхідних запитів на зміни, що вказує на те, що його слід переглянути, хто є відповідальною стороною. Змінивши стан до цього, вони можуть легко бачити історію (факт, яку було відкладено раніше), а також нову інформацію легко.

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

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

По суті, вам дійсно доведеться викопати помилку та виправити помилку, і якщо ви все ще думаєте, що це має бути виправлено, тоді введіть помилку.

Як програміст, я думаю, що дублювання інформації - це взагалі погана річ, і її слід уникати, коли це можливо. Уявіть таблицю "Проблеми" в базі даних помилок. Кожен запис у цій таблиці повинен представляти унікальну проблему. Коли ви додаєте другу запис для тієї ж помилки, вона насправді починає представляти не саму помилку, а те, що якийсь користувач виявив її та опублікував у якусь дату та час. Насправді трапилось те, що ви розмістили додаткову інформацію про існуючу проблему. Цю інформацію слід зберігати в іншому місці, як-от таблиця "IssueComments" або щось подібне.

З моєї точки зору, некромантія - це менше зла. Якщо некромантія - це проблема, ми повинні боротися з чимось, що спричиняє проблему, а не з самою некромантією (якщо ви знайшли якусь нову інформацію про стару помилку, що з цим погано? Це цілком природно). Наприклад, якщо хтось публікує коментар до старої закритої помилки, це має якось привернути увагу всіх зацікавлених користувачів.

Можливо, ви могли б відкрити новий звіт про помилку та пов’язати його зі старим. Обґрунтуйте свої причини, що хочете виправити. Можливо, виправлення порушить існуючу поведінку (або двійкова сумісність, або змінить спосіб роботи з додатком), і виправлення може спричинити більше проблем, ніж це варто. Якщо виправлення мало б мінімальний вплив, можливо, заперечень щодо його виправлення не може бути.

Потрібно точно зрозуміти, чому було вирішено не виправляти в першу чергу.

Я б сказав, що це відрізняється від помилки та запиту на функції.

Коли ви створюєте звіт про помилки в програмі виправлення помилок, ви зазвичай описуєте симптоми. Однак це не означає, що основна причина однакова або навіть схожа. Особливо, якщо внутрішні файли добре приховані від кінцевого користувача, і все, що ви отримуєте, - це загальна помилка, коли щось пішло не так. У таких випадках некромантія - це не шлях, оскільки подія, хоча зовнішні симптоми можуть здатися схожими, це, швидше за все, зовсім інші помилки. Якщо ви знову відкриєте стару помилку, розробник, ймовірно, почне досліджувати стару причину, що може призвести його до повного неправильного напрямку та втрати часу.

Для запиту на функції, який було відхилено, а причини відхилення більше не дійсні, я б сказав, що некромантія - це шлях. У цьому випадку ви знаєте, що створюючи новий квиток, ви створювали б точний дублікат.