バグ追跡エチケット-ネクロマンシーまたは重複？

要求された拡張を行うために必要なツールが不足しているため、「解決済み（修正しない）」とマークされたオープンソースプロジェクトのバグトラッカーで、非常に古い（2年以上）機能要求の問題に遭遇しました。その決定がなされてから経過した時間の中で、それを解決することを可能にする新しいツールが開発されました、そして、私はそのアプリケーションのためにコミュニティの注意を喚起したいと思います。

ただし、このような場合に一般的に受け入れられているエチケットがバグ追跡のためのものであるかどうかはわかりません。明らかに、システムが複製しないことを明示的に宣言し、新しいアイテムを複製としてアクティブにマークする場合（SEサイトの場合と同様）、答えはシステムが言うことに従うことです。しかし、システムが明示的にそれを言っていない場合、または新しいユーザーがシステムの好みで言う場所を簡単に見つけることができない場合はどうですか？一般に、複製または壊死の側で誤りを犯す方が良いと考えられますか？これはバグか機能リクエストかによって異なりますか？

これに適切に答えることができるのは、組織のプロセスだけです。この状況が定義されていない場合は、発生するたびに一貫性があるように定義する必要があります。

古いものを再度開き、必要に応じて新しい情報を追加することをお勧めします。測定/メトリックの観点から、これはおそらく最も有害ではないでしょう。新しいことは新しい欠陥や機能強化ではなく、古い欠陥を再訪することです。着信変更要求には、責任者が誰でもレビューする必要があることを示す状態が必要です。状態をこれに戻すことで、彼らは履歴（以前は一度延期されたという事実）だけでなく、新しい情報も簡単に見ることができます。

私がやる（そして過去にした）ことは、（関連性を与えるために）新しいバグを作成し、可能性のある/新しい修正を記録し、歴史的な参照/追跡のために古いものにリンクすることです。

また、バグにも依存します...そのバグは現在「機能」であるか、または人々が修正によって壊れるであろう2年間使用している十分に確立された回避策があるかもしれません。

基本的に、本当にバグと潜在的な修正を掘り下げて調査する必要があり、それでも修正する必要があると思われる場合は、バグを記録します。

プログラマーとして、情報の複製は一般に悪いことであり、可能な限り避けるべきだと思います。バグ追跡データベースの「問題」のテーブルを想像してください。この表の各レコードは、固有の問題を表す必要があります。同じバグに2番目のレコードを追加すると、実際にはバグ自体ではなく、一部のユーザーがそれを発見して何らかの日時に投稿したという事実を表し始めます。実際に起こったことは、既存の問題に関する追加情報を投稿したことです。この情報は、「IssueComments」テーブルなどの別の場所に保存する必要があります。

私の観点から見ると、ネクロマンシーはそれほど悪ではありません。ネクロマンシーが問題である場合、ネクロマンシー自体ではなく、問題を引き起こす何かと戦う必要があります（古いバグに関する新しい情報を見つけた場合、それは何が悪いのでしょうか？それは全く自然です）。たとえば、誰かが古いクローズドバグに関するコメントを投稿した場合、これは何らかの形ですべての関心のあるユーザーの注意を引くはずです。

おそらく、新しいバグレポートを開いて、古いレポートにリンクできます。修正したい理由を正当化します。修正により、既存の動作（バイナリ互換性またはアプリケーションでの動作方法の変更）が中断され、修正すると価値以上の問題が発生する可能性があります。修正による影響が最小限であれば、修正されることに異論はないかもしれません。

そもそも修正しないことにした理由を正確に確認する必要があります。

これは、バグと機能要求の間で異なると思います。

バグトラッカーでバグレポートを作成するとき、通常は症状を説明しています。しかし、根本的な原因が同じである、または類似していることさえ意味しません。特に、内部がエンドユーザーから十分に隠されていて、何かがうまくいかなかった場合に発生する一般的なエラーだけです。そのような場合、外部症状は似ているように見えるかもしれませんが、おそらく完全に異なるバグであるため、ネクロマンシーは進むべき道ではありません。古いバグを再び開くと、開発者はおそらく古い原因の調査を開始します。これにより、彼は完全に間違った方向に進み、時間を失うことになります。

拒否された機能のリクエストで、拒否の理由が無効になった場合、ネクロマンシーが解決策であると思います。この場合、新しいチケットを作成すると、完全に複製することになります。