Etykieta śledzenia błędów - nekromancja czy duplikat?

Natrafiłem na bardzo stary (ponad 2 lata) problem z żądaniem funkcji w narzędziu do śledzenia błędów w projekcie open source, który został oznaczony jako „rozwiązany (nie naprawi się)” z powodu braku narzędzi wymaganych do wprowadzenia wymaganego ulepszenia. W czasie, który upłynął od podjęcia tej decyzji, opracowano nowe narzędzia, które pozwoliłyby na jej rozwiązanie, i chciałbym zwrócić uwagę społeczności na tę aplikację.

Nie jestem jednak pewien, jaka jest ogólnie przyjęta etykieta śledzenia błędów w takich przypadkach. Oczywiście, jeśli system wyraźnie oświadczy, że nie powiela się i będzie aktywnie oznaczać nowe elementy jako duplikaty (podobnie jak robią to strony SE), odpowiedzią byłoby śledzenie tego, co mówi system. Ale co z tym, że system nie mówi tego wprost lub nowy użytkownik nie może łatwo znaleźć miejsca, które mówi preferencje systemu? Czy ogólnie uważa się za lepsze popełnienie błędu po stronie powielania lub nekromancji? Czy różni się to w zależności od tego, czy jest to błąd, czy żądanie funkcji?

Jedyną rzeczą, która może odpowiednio odpowiedzieć na to pytanie, jest proces Twojej organizacji. Jeśli ta sytuacja nie jest zdefiniowana, należy ją zdefiniować, aby była spójna za każdym razem, gdy się zdarzy.

Zalecam ponowne otwarcie starego i dodanie do niego odpowiednio nowych informacji. Z punktu widzenia pomiarów / pomiarów byłoby to prawdopodobnie najmniej szkodliwe - nowa rzecz nie jest nową wadą ani ulepszeniem, ale raczej przeglądem starej. Powinien istnieć pewien stan dla przychodzących wniosków o zmianę, który wskazuje, że musi to zostać sprawdzone przez osobę odpowiedzialną. Zmieniając stan z powrotem na to, mogą łatwo zobaczyć historię (fakt, że raz ją odroczono), ale także nowe informacje.

To, co zrobiłbym (i zrobiłem w przeszłości), to stworzyć nowy błąd (aby nadać mu trafność), zanotować możliwą / nową poprawkę i link do starego w celu odniesienia do historii / śledzenia.

zależy to również od błędu ... ten błąd może być teraz „funkcją” lub mieć dobrze ugruntowane obejścia, z których ludzie korzystają od 2 lat, które byłyby zepsute przez poprawkę.

Zasadniczo naprawdę musisz przekopać się i zbadać błąd i potencjalną poprawkę, a jeśli nadal uważasz, że powinna zostać naprawiona, zaloguj się.

Jako programista uważam, że powielanie informacji jest na ogół złe i należy tego unikać, gdy tylko jest to możliwe. Wyobraź sobie tabelę „Problemy” w bazie danych śledzenia błędów. Każdy rekord w tej tabeli powinien stanowić unikalny problem. Po dodaniu drugiego rekordu dla tego samego błędu, faktycznie zaczyna on reprezentować nie sam błąd, ale fakt, że jakiś użytkownik go odkrył i opublikował pewnego dnia i godziny. W rzeczywistości opublikowałeś dodatkowe informacje o istniejącym problemie. Informacje te powinny być przechowywane w innym miejscu, np. W tabeli „IssueComments” lub w podobnej formie.

Z mojego punktu widzenia nekromancja jest mniej zła. Jeśli nekromancja jest problemem, powinniśmy walczyć z czymś, co powoduje problem, a nie z samą nekromancją (jeśli znalazłeś jakieś nowe informacje o starym błędzie, co jest z tym nie tak? Jest to całkowicie naturalne). Na przykład, jeśli ktoś opublikuje komentarz do starego zamkniętego błędu, powinien to w jakiś sposób przyciągnąć uwagę wszystkich zainteresowanych użytkowników.

Być może mógłbyś otworzyć nowy raport o błędach i połączyć go ze starym. Uzasadnij powody, dla których chcesz to naprawić. Może się zdarzyć, że poprawka zepsuje istniejące zachowanie (zgodność binarna lub zmieni sposób, w jaki muszą pracować z aplikacją), a naprawienie jej może spowodować więcej problemów niż jest to warte. Jeśli poprawka miałaby minimalny wpływ, być może nie ma zastrzeżeń do jej naprawienia.

Musisz przede wszystkim dokładnie zrozumieć, dlaczego zdecydowano się nie naprawiać.

Powiedziałbym, że różni się to między żądaniem błędu a funkcją.

Kiedy tworzysz raport o błędzie w Bugtrackerze, zwykle opisujesz objawy. Nie oznacza to jednak, że podstawowa przyczyna jest taka sama lub nawet podobna. Zwłaszcza jeśli elementy wewnętrzne są dobrze ukryte przed użytkownikiem końcowym, a otrzymujesz tylko ogólny błąd, gdy coś poszło nie tak. W takich przypadkach nekromancja nie jest właściwą drogą, ponieważ chociaż objawy zewnętrzne mogą wydawać się podobne, najprawdopodobniej jest to zupełnie inny błąd. Jeśli ponownie otworzysz stary błąd, programista prawdopodobnie zacznie badać starą przyczynę, co może doprowadzić go w zupełnie złym kierunku i stracić czas.

W przypadku żądania funkcji, które zostało odrzucone, a przyczyny odrzucenia nie są już ważne, powiedziałbym, że nekromancja jest właściwym rozwiązaniem. W takim przypadku wiesz, że tworząc nowy bilet, tworzysz dokładny duplikat.