Bug Tracking-Etikette - Nekromantie oder Duplikat?

Ich bin auf ein sehr altes Feature-Request-Problem (über 2 Jahre) in einem Bug-Tracker für ein Open-Source-Projekt gestoßen, das als "behoben (nicht behoben)" markiert wurde, da für die angeforderte Verbesserung keine Tools erforderlich waren. In der Zeit, die vergangen ist, seitdem diese Entscheidung getroffen wurde, wurden neue Tools entwickelt, mit denen sie gelöst werden können, und ich möchte die Community für diese Anwendung darauf aufmerksam machen.

Ich bin mir jedoch nicht sicher, wie die allgemein akzeptierte Etikette für die Fehlersuche in solchen Fällen aussieht. Wenn das System ausdrücklich angibt, keine Duplikate zu erstellen, und neue Elemente aktiv als Duplikate markiert (ähnlich wie bei den SE-Sites), lautet die Antwort, den Anweisungen des Systems zu folgen. Aber was ist, wenn das System das nicht explizit sagt oder ein neuer Benutzer nicht leicht einen Ort finden kann, der mit der Präferenz des Systems übereinstimmt? Wird es allgemein als besser angesehen, auf der Seite der Vervielfältigung oder Nekromantie zu irren? Unterscheidet sich dies je nachdem, ob es sich um einen Fehler oder eine Funktionsanforderung handelt?

Das Einzige, was dies angemessen beantworten kann, ist der Prozess Ihres Unternehmens. Wenn diese Situation nicht definiert ist, sollte sie so definiert werden, dass sie bei jedem Auftreten konsistent ist.

Ich würde empfehlen, die alte erneut zu öffnen und gegebenenfalls neue Informationen hinzuzufügen. Aus der Perspektive von Messungen / Metriken wäre dies wahrscheinlich am wenigsten schädlich - die neue Sache ist kein neuer Defekt oder eine neue Verbesserung, sondern ein erneuter Besuch einer alten. Es sollte einen Status für eingehende Änderungsanforderungen geben, der angibt, dass diese von der verantwortlichen Partei überprüft werden müssen. Indem sie den Status wieder in diesen zurückversetzen, können sie die Historie (die Tatsache, dass sie zuvor einmal zurückgestellt wurde), aber auch die neuen Informationen leicht einsehen.

Ich würde (und habe es in der Vergangenheit getan) einen neuen Bug erstellen (um ihm Relevanz zu verleihen), die mögliche / neue Korrektur notieren und einen Link zu der alten für die historische Referenz / Verfolgung erstellen.

es kommt auch auf den Fehler an ... dieser Fehler könnte jetzt ein "Feature" sein oder gut etablierte Workarounds haben, die die Leute seit 2 Jahren verwenden und die durch einen Fix kaputt gehen würden.

Grundsätzlich müssen Sie den Fehler und die mögliche Fehlerbehebung gründlich untersuchen. Wenn Sie dennoch der Meinung sind, dass er behoben werden sollte, protokollieren Sie den Fehler.

Als Programmierer denke ich, dass das Duplizieren von Informationen im Allgemeinen eine schlechte Sache ist und nach Möglichkeit vermieden werden sollte. Stellen Sie sich eine Tabelle "Probleme" in der Bug-Tracker-Datenbank vor. Jeder Datensatz in dieser Tabelle sollte ein eindeutiges Problem darstellen. Wenn Sie einen zweiten Datensatz für denselben Fehler hinzufügen, wird tatsächlich kein Fehler selbst angezeigt, sondern die Tatsache, dass ein Benutzer ihn entdeckt und an einem bestimmten Datum und zu einer bestimmten Uhrzeit veröffentlicht hat. Was tatsächlich passiert ist, ist, dass Sie einige zusätzliche Informationen zu einem bestehenden Problem veröffentlicht haben. Diese Informationen sollten an einem anderen Ort gespeichert werden, z. B. in der Tabelle "IssueComments" oder ähnlichem.

Aus meiner Sicht ist Nekromantie weniger böse. Wenn Nekromantie ein Problem ist, sollten wir mit etwas kämpfen, das ein Problem verursacht, nicht mit Nekromantie selbst (wenn Sie neue Informationen über alte Fehler gefunden haben, was ist daran falsch? Es ist völlig natürlich). Wenn zum Beispiel jemand einen Kommentar zu einem alten geschlossenen Fehler veröffentlicht, sollte dies die Aufmerksamkeit aller interessierten Benutzer auf sich ziehen.

Vielleicht können Sie einen neuen Fehlerbericht öffnen und ihn mit dem alten verknüpfen. Begründen Sie Ihre Gründe für die Behebung. Es kann vorkommen, dass das Update das vorhandene Verhalten beeinträchtigt (entweder die Binärkompatibilität oder die Art und Weise, wie sie mit der Anwendung arbeiten) und mehr Probleme verursacht, als es wert ist. Wenn das Update nur minimale Auswirkungen haben würde, gibt es möglicherweise keine Einwände dagegen, dass es behoben wird.

Sie müssen genau wissen, warum entschieden wurde, das Problem überhaupt nicht zu beheben.

Ich würde sagen, dies unterscheidet sich zwischen Fehler- und Funktionsanforderung.

Wenn Sie im Bugtracker einen Fehlerbericht erstellen, beschreiben Sie in der Regel Symptome. Dies bedeutet jedoch nicht, dass die zugrunde liegende Ursache gleich oder sogar ähnlich ist. Vor allem, wenn Interna vor Endbenutzern gut verborgen sind und nur ein allgemeiner Fehler auftritt, wenn ein Fehler auftritt. In solchen Fällen ist Nekromantie nicht der richtige Weg, da äußere Symptome zwar ähnlich erscheinen, es sich jedoch höchstwahrscheinlich um einen völlig anderen Fehler handelt. Wenn Sie den alten Bug erneut öffnen, beginnt der Entwickler wahrscheinlich, die alte Ursache zu untersuchen, was dazu führen kann, dass er völlig in die falsche Richtung geht und Zeit verliert.

Für Feature-Anfragen, die abgelehnt wurden und deren Ablehnungsgründe nicht mehr gültig sind, ist Nekromantie der richtige Weg. In diesem Fall wissen Sie, dass Sie beim Erstellen eines neuen Tickets ein genaues Duplikat erstellen würden.