GitHubで放棄された問題をどうするか？

誰かがGitHubで問題を開いたが、エラーを再現するための詳細な情報が求められ、それが与えられない場合、通常の手順は何ですか？例。

ここで著者は「nav breaks」と述べています。私はそれが修正されたと信じていますが、私たちが同じことについて話していることを確認するために著者からの一言をお願いします。ただし、問題のレポーターが消える場合があります。放棄された問題の有効期限を設定することは良い/一般的な慣行ですか？

これらの条件のようなもの：

• 問題をデバッグできるようにするために、問題に関する質問が発生します。
• 開発チームからの最後の未回答の質問/コメントから2〜6か月以上が経過しています。
• バグはクローズ時に再現できません（何らかの理由で、再現できない可能性があります）。
• 警告は、それを閉じる2週間前に発行されます。

プロジェクトは通常何をしますか？Googleで何も見つかりませんでした。また、これをどのように文書化しますか？上記のポイントを詳述したREADME.mdの簡単なメモと、閉じられた理由を説明する問題のコメントで十分ですか？

注：バグはまだ関連している（または関連していない）可能性があるため、この質問とは異なりますが、情報が不足しています。

これはジレンマです。問題を「修正済み」としてクローズすることはできません。修正されたかどうかは実際にはわからないため、少なくとも何らかの問題が修正されたとしても、これがレポーターの問題であるかどうかは実際にはわかりません話していました。一方、修正された可能性のある問題は、特に確認が得られないため閉じることができない場合は残したくないでしょう。

したがって、閉じる必要がありますが、おそらく「修正済み」ではありません。肯定的になりたい場合は「maybefixed」または「unconfirmedfix」、そうでない場合は「reportervanished」というカスタムのクローズ理由を作成できます。また、「再現できませんでした」と言って、同じバグがポップアップしてより反応の良いレポーターが現れるのを待つこともできます。

ただし、バグが実際に修正されたかどうかがわからないバグにリソースを費やすべきではありません。

あなたの主な質問はすでに回答されていますが、プロセスの文書化についても質問しました。それも回答する必要があります。

私が多くのプロジェクトで見た解決策は、プロジェクトのREADME.mdではなく、特別な貢献 README- 貢献者向けのREADMEファイルに置くことです。このファイルは、プロジェクトに貢献している人々に知ってもらいたいすべてのことを記述しています-コード（命名規則、モジュール編成など）またはプロセス（コミットの書き方、チケットの処理方法など）についてです。このファイルは.MD、プロジェクト内の別のファイルにすることも、まったく異なるリポジトリに配置することもできます（したがって、すべてのプロジェクトで共有できます）。メインからリンクすることを忘れないでくださいREADME.md！

メインREADMEからその情報を分離するポイントは、通常、プロジェクトのユーザーのほんの一部だけが直接貢献しているということです。ほとんどのユーザーは、その情報に飽き飽きする必要はありません。プロジェクトが何をするのか、どのように使用するのかを知るだけでよく、それがメインのREADMEに含まれている必要があります。プロジェクトの場合、コントリビューションセクションは非常に小さいため、メインのREADMEを妨げることはありませんが、コントリビューターがフォローしたいすべてのワークフローを文書化すると、コントリビューターはそれ以上うまく適合しません...

すべてのユーザーがバグを開くことができることに注意してください。したがって、バグのオープンに関する特別な要件がある場合は、メインのREADMEに入れてくださいあなたの規則を勉強し、順守するため）。ただし、実際にバグを修正してチケットをクローズする人（あなたまたは確認したコントリビューターのいずれか）は直接コントリビューターであり、コントリビューションのREADMEを読むことが期待できます。応答しないことはそこに記述されるべきです。

これは、未検証のバグを（githubの課題追跡を使用して）処理する方法に関する実践に関する質問として他の何よりも読みました。

私にとって、それは私が使用した他の課題追跡システムに基づいたかなり単純な答えです。Githubは、だれにもワークフローの使用を強制することはありません。これにより、非常に柔軟になり、デフォルト設定では役に立たなくなります。

Bugzillaのデフォルトのワークフローを見ると、次のものが得られます。

私はそこに非常に重要なことを指摘するつもりです-それを取得決議として固定それがされる前に閉鎖された後に検証します。基本的なGithubワークフローには、赤（開いている）と緑（閉じている）の状態のみが表示されます。

したがって、1つのアプローチは、Github内のラベル（アプリケーションのラベル）を使用して、追加情報を表示しようとすることです。問題を閉じると適用される「未検証」と「検証済み」のラベルのペアを作成できます。これは1つのアプローチにすぎないことに注意してください。検索すると、ラベルの使用に対する多数の異なるアプローチを見つけることができます。ここで、（優先度など）のgithubの問題を管理する方法の質問？これに対処します。

あなたはそれを修正しました。開発者の観点からはそれは行われています。Githubで問題を閉じます。「未検証」ラベルを適用します。前のバージョンのバグに詳しい人が「はい、これで修正しました」と言ったら、ラベルを「検証済み」に変更できます。彼らがそうしなかったと言うならば、あなたはそれを再び開きます。

また、「修正済み」以外にも他の解決済み状態があることに注意してください。「wontfix」（修正は現在の構造ではできません）と「worksforme」（バグは再現できません）および「invalid」（OSに関するバグを提出していますが、アプリケーションタイプの事柄）。

私は、元のレポーターと同じことについて話しているという自信に応じて、2つの見解のうちの1つを取ります。

1）レポーターは使用できなくなっているため、問題のバグは修正したものを意味するとみなします。役立つ場合は、テストケースを添付して、発見した障害を明確にします。バグレポートに修正内容を詳しく説明し、「これが「nav breaks」の意味だと思います。意図していない場合は、新しいバグを再度開くか、発生させてください」バグを修正済みとしてマークします。

2）レポーターは利用できなくなっているため、バグはレポーターの言葉だけで報告されたものと同じであることを確認するため、バグを再現することはできません。修正したものを説明するために新しいバグを作成します。不在のレポーターによって説明された条件の下で観察されたという信用の言及のために、重複する可能性があることに注意し、新しいバグを修正済みとしてマークし、このバグを無効または「nav breaks」の意味を理解できないが、見つけた問題を解決した。「nav breaks」がまだ壊れている場合は、再度開くか、新しいバグを報告してください。問題の詳細」を参照してください。

タイムスケールに関しては、プロジェクトに依存すべきだと思います。応答が非常に速く、バグが発生してから数日以内にこのバグに対処している場合、人々は問題を解決する前に応答を数週間待たないことを理解する必要があります。一方、それが数ヶ月間あなたのスラッシュパイルにあったなら、あなたは何も問題を引き起こすことなく、もう1、2ヶ月開いたままになります。

このため、「グッドプラクティス」を構成する特定の時間制限があるとは思いません。また、ポリシーを公開してそれに従う必要があるとは思いません。確かに、あなたが彼らに連絡する努力をするまでレポーターに連絡できないことを記録したくないでしょう。しかし、複数の警告が期限までカウントダウンされることを意味することもありません。バグを再訪して何か言いたいと思うか、そうでないかのどちらかです。