バグ追跡エチケット-ネクロマンシーまたは重複？
要求された機能強化を行うために必要なツールがないため、「解決済み（修正されません）」とマークされたオープンソースプロジェクトのバグトラッカーで、本当に古い（2年以上）機能リクエストの問題に遭遇しました。その決定がなされてからの経過時間の中で、それを解決できるようにする新しいツールが開発されました。私は、そのアプリケーションについてコミュニティの注意を喚起したいと思います。
ただし、このような場合のバグ追跡用に一般に受け入れられているエチケットが何かはわかりません。明らかに、システムが重複しないことを明示的に示し、新しいアイテムを重複として積極的にマークする場合（SEサイトが行うように）、答えはシステムが言うことに従うことです。しかし、システムが明示的にそれを言わない場合、または新しいユーザーがシステムの好みで言う場所を簡単に見つけることができない場合はどうでしょうか？一般的に、複製またはネクロマンシーの側に誤りがある方が良いと考えられていますか？これはバグか機能リクエストかによって異なりますか？
これに適切に対応できる唯一のことは、組織のプロセスです。この状況が定義されていない場合は、発生するたびに一貫するように定義する必要があります。
古いものをもう一度開き、必要に応じて新しい情報を追加することをお勧めします。測定/メトリックの観点からは、これはおそらく最も害が少ないでしょう。新しいことは新しい欠陥や拡張ではなく、古いものを再検討することです。責任者がだれでも誰でもそれをレビューする必要があることを示す、着信変更要求には何らかの状態があるはずです。状態をこれに戻すことで、履歴（以前に延期されたという事実）だけでなく、新しい情報も簡単に確認できます。
私がやろうとしていること（および過去に行ったこと）は、新しいバグを作成し（関連性を持たせるため）、可能性のある/新しい修正を記録し、履歴参照/追跡のために古い修正にリンクします。
それはバグにも依存します...そのバグは現在「機能」であるか、または修正によって破壊されるだろう人々が2年間使用してきた確立された回避策があるかもしれません。
基本的に、実際に調査してバグと潜在的な修正を調査する必要があり、それでも修正する必要があると思われる場合は、バグを記録します。
プログラマーとして、情報の複製は一般的に悪いことであり、可能な限り回避する必要があると思います。バグ追跡データベースの「問題」テーブルを想像してください。この表の各レコードは、固有の問題を表す必要があります。同じバグの2番目のレコードを追加すると、実際にはバグそのものではなく、一部のユーザーがそれを発見して特定の日時に投稿したという事実を表し始めます。実際に起こったことは、既存の問題に関する追加情報を投稿したことです。この情報は、「IssueComments」テーブルなどの別の場所に保存する必要があります。
私の見解では、ネクロマンシーはそれほど危険ではありません。ネクロマンシーが問題である場合は、ネクロマンシー自体ではなく、問題を引き起こしているものと戦う必要があります（古いバグに関する新しい情報を見つけた場合、何が悪いのでしょうか？それはまったく自然なことです）。たとえば、誰かが古いクローズしたバグにコメントを投稿した場合、これは何らかの方法ですべての関心のあるユーザーの注意を引くはずです。
おそらく、新しいバグレポートを開いて、古いバグレポートにリンクできます。それを修正したい理由を正当化してください。修正が既存の動作を破壊し（バイナリ互換性、またはアプリケーションでの動作方法を変更する）、修正することにより、それよりも多くの問題が発生する可能性があります。修正による影響が最小限の場合は、修正することに異論がない可能性があります。
そもそも修正しないことが決定された理由を正確に理解する必要があります。
これはバグと機能のリクエストで異なると思います。
バグトラッカーでバグレポートを作成するとき、通常は症状を説明しています。ただし、根本的な原因が同じまたは類似しているという意味ではありません。特に内部がエンドユーザーから十分に隠されていて、何かがうまくいかなかった場合に得られるのは一般的なエラーだけです。そのような場合、外見の症状は似ているように見えるかもしれませんが、完全に異なるバグである可能性が高いため、ネクロマンシーは進むべき道ではありません。古いバグを再度開くと、開発者はおそらく古い原因の調査を開始するでしょう。そのため、開発者は完全に間違った方向に進み、時間を失う可能性があります。
拒否された機能のリクエストで、拒否の理由が無効になった場合、ネクロマンシーが有効です。この場合、新しいチケットを作成すると完全に重複して作成されることになります。