GitHubで放棄された問題をどうするか？
誰かがGitHubで問題を開いたが、エラーを再現するための詳細情報が要求され、決して提供されない場合、通常の手順は何ですか？ 例 。
ここで著者は「ナビゲーションが壊れる」と述べています。私はそれが修正されたと信じていますが、筆者からのWordで、同じことについて話していることを確認してください。しかし、時々問題の記者はちょうど消えます。破棄された問題の有効期限を設定することは良い/一般的な方法ですか？
これらの条件のようなもの：
- デバッグできるように問題について質問が出されます。
- 開発チームからの最後の未回答の質問/コメントから2〜6か月が経過しました。
- クローズ時にバグを再現することはできません（何らかの理由で、再現できない可能性があります）。
- 閉鎖の2週間前に警告が出されます。
プロジェクトは通常何をしますか？ Googleで何も見つかりませんでした。また、これをどのように文書化しますか？ README.mdに上記のポイントの詳細を記した簡単なメモと、問題がクローズされる理由を説明する問題のコメントで十分ですか？
注：これは この質問 とは異なります。バグがまだ関連している（または関連していない）可能性があるためですが、情報が不足しています。
これはジレンマです。実際にはifが修正されたか、少なくともsomeの問題が修正されたとしても、あなたは知らないため、問題を「修正済み」として閉じることはできません。 、これが記者が話していた問題であったかどうかは実際にはわかりません。一方で、特に確認が得られないために閉じることができない場合は特に、修正された可能性のある問題を開いたままにしたくないでしょう。
したがって、あなたはすべき閉じますが、おそらく「修正済み」ではありません。ポジティブになりたい場合は「maybefixed」または「unconfirmedfix」、そうでない場合は「reportervanished」というカスタムのクローズ理由を作成できます。また、単に「再現できませんでした」と言って、同じバグがポップアップするのを待って、応答性の高いレポーターを作成することもできます。
ただし、実際に修正されたかどうかわからないバグにリソースを費やすことはできません。
あなたの主な質問はすでに回答されていますが、プロセスを文書化することについても質問されました。
多くのプロジェクトで見た解決策は、プロジェクトのREADME.mdではなく、特別なcontribution README-a README寄稿者用のファイル）に置くことです。このファイルは、コードに関係する人（命名規則、モジュール編成など）またはプロセス（コミットの書き込み方法、チケットの処理方法など）に関係なく、プロジェクトに貢献する人々に知ってほしいすべてのものを記述します。このファイルは別の.MDファイルをプロジェクト内に配置するか、完全に異なるリポジトリに配置します（すべてのプロジェクト間で共有できます）。メインからリンクすることを忘れないでくださいREADME.md！
その情報をメインから分離するポイントREADMEは、通常、プロジェクトのユーザーの一部のみが直接それに貢献することです。ほとんどのユーザーはその情報に飽きる必要はありません-彼らはあなたのプロジェクトが何をしてそれをどのように使うかを知る必要があるだけで、それがメインのREADMEに含まれるべきものです。プロジェクトの場合、contributionセクションは非常に小さいのでメインREADME-を妨げるものではありませんが、コントリビューターにフォローしてもらいたいすべてのワークフローを文書化すると、ワークフローにうまく適合しなくなります...
どのユーザーもバグをオープンできることに注意してください。バグのオープンに関して特別な要件がある場合は、メインのREADMEにそれらを配置する必要があります（ただし、コードの寄稿者とは異なり、バグレポーターはおそらく長々と進んでいきません。勉強し、あなたのルールに準拠するため）。ただし、実際にバグを修正してチケットを閉じる人（あなたまたはあなたが確認した寄稿者の1人）は直接の寄稿者であり、寄稿を読むことが期待できますREADME-soレポーターが応答しないときにチケットをクローズするプロセスはそこに記述されるべきです。
私はこれを、（githubの課題追跡を使用して）未確認のバグを処理する方法に関する他の何よりも実践に関する質問として読んだ。
私にとっては、これは私が使用した他の課題追跡システムに基づいたかなり簡単な答えです。 Githubは誰もがワークフローを使用することを強制しないため、非常に柔軟になり、デフォルトの構成では役に立たなくなります。
Bugzillaのデフォルトのワークフローを見ると、次のようになります。
私はそこで非常に重要なことを指摘します-それはresolvedを取得しますfixed取得する前にclosed後にverified。基本的なGithubワークフローでは、赤（オープン）と緑（クローズ）の状態のみが表示されます。
したがって、1つのアプローチは、Github内のラベル（ アプリケーションのラベル ）を使用して、追加情報を表示することです。問題を閉じると適用される「未確認」と「確認済み」のラベルのペアを作成できます。これは1つのアプローチにすぎないことに注意してください。検索すると、ラベルの使用に関するさまざまなアプローチを見つけることができます。ここで、質問 （優先度など）のgithubの問題を管理する方法？ はこれに対処します。
あなたはそれを修正しました、開発者の観点からそれは行われます。 Githubで問題を閉じます。 「未確認」のラベルを付けます。以前のバージョンのバグに詳しい人が「はい、これで修正しました」と言ったら、ラベルを「確認済み」に変更できます。彼らがそうしなかったと彼らが言ったなら、あなたはそれを再び開きます。
また、「修正済み」のほかにother解決済みの状態があることに注意してください。 'wontfix'（修正は現在の構造では実行できないものです）と 'worksforme'（バグは再現できません）と 'invalid'（OSに関するバグを提出しているのではなく、アプリケーションの種類の物）。
私は、元のレポーターと同じことについて話していたとの確信に応じて、2つのビューのうちの1つを取ります。
1）レポーターが利用できなくなったので、問題のバグが修正した内容を意味すると見なします。問題が解決しない場合は、テストケースを添付して、見つかったエラーを明確にします。バグレポートの詳細を説明し、「ナビゲーションの中断」の意味だと思います。意図していない場合は、再度開くか、新しいバグを報告してください」のようなメモを残します。バグを修正済みとしてマークします。
2）レポーターが利用できなくなったため、レポーターのWordだけが彼らが報告したものと同じであることを確認するため、バグは再現できない（既知である）と見なします。あなたが修正したことを説明するために新しいバグを発生させてください。信用のために、それが不在のレポーターによって説明された条件下で観察されたことを両方とも注意してくださいかもしれない重複している、新しいバグをマークしてください修正し、これを無効または再現できないようにマークします。たとえば、「ナビゲーションの中断」の意味を理解できませんが、見つけた問題は解決しました。再オープンするか、新しいバグを報告してください。ナビゲーションはまだ壊れており、問題の詳細を説明しています。」.
タイムスケールについては、プロジェクト次第だと思います。非常に対応が早く、問題が発生してから数日以内にこのバグに対処している場合、問題を解決する前に何週間も応答を待たないことを人々は理解する必要があります。一方、それがあなたのスラッシュパイルに数ヶ月置かれているなら、それはあなたに何の問題も引き起こさずにさらに1、2ヶ月開いたままでいることができます。
このため、「良い習慣」を構成する特定の時間制限があるとは思いません。または、ポリシーを公開してそれに固執する必要があるとは思いません。確かに、あなたが彼らに連絡する努力をするまで、レポーターに連絡できないことを記録したくないでしょう。しかし、複数の警告が期限までカウントダウンしてしまう点も見当たらない。彼らはバグを再訪して何か言いたいことがあるのか、そうでないのか。