有意義な問題報告を作成するためのガイドライン¶
このセクションでは、|Gromacs|の`issue tracker`_で、役立つレポートを作成するための手順を説明しています。この情報は、主にそのドキュメントから直接得られたものであり、レポート作成の際に役立ちます。
報告すべき内容¶
問題が発生したことを確認し、|Gromacs|が意図しない方法で動作していることを特定し、可能な範囲で調査した問題のみを報告してください。大規模なシミュレーションが途中で失敗する場合は、より簡単にデバッグできる小さなテストケースを使用して、問題の発生を再現してみてください。
サードパーティソフトウェアの使用によって発生したバグについては、まず調査を行い、問題が|Gromacs|にあることを確認する必要があります。
システム不安定やシステムが「クラッシュ」するなどの原因で発生する、一般的な問題を提出しないでください。
記載すべき内容¶
レポートには、GROMACS に関する問題の一般的な説明を含める必要があります。これは、期待される動作と実際の結果の両方を明示する必要があります。問題がプログラムのクラッシュを引き起こす場合は、レポートにはクラッシュが発生する場所を特定し、可能な場合はクラッシュに至るまでのスタックトレースを含める必要があります。
すべてのバグには、開発者がエラーを再現するために必要な情報を含める必要があります。これには、必要な場合に最小限の入力ファイル（*tpr、*top、*mdpなど）、実行コマンドまたは最小限のスクリプトのバージョン、|Gromacs|のコンパイル方法、および可能な限りシステムアーキテクチャが含まれます。
開発者が簡単に理解できる、自己完結型でエラーや警告が発生しない、*最小限の*動作例を作成することが重要です。もし、あなたの例でエラーが発生する場合は、その問題は*現実的な*問題とは見なされず、少なくとも問題を特定し解決することが非常に難しくなります。
もし、あなたの入力が機密情報を含む場合、開発チームが問題を解決できるように、プライベートな「問題」を作成することができます。これにより、インターネット上での広範な公開を防ぎながら、開発チームが問題を解決できるようになります。
開発者を支援する¶
通常、開発者がプログラムに関する質問に答えることができるはずです。問題を見つけた場合、開発者を支援するために、問題を修正するのに役立つ情報を提供することが含まれます。これには、実行スクリプトやシミュレーションの設定の説明、およびプログラムとさまざまなバージョンのライブラリおよびコンパイラの組み合わせに関する問題の確認が含まれます。
目標バージョンを設定したり、不合理な優先順位を決定したりすることは避けてください。もしご自身で問題を修正する場合は、関連するページに記載されている他の基準：ref:自動ソースコードフォーマット および Git コミットのフォーマットに関するガイドライン に従ってください。
参考
貢献
一般的な問題解決の流れ¶
一般的なワークフローは、以下の図に示されています。
プロジェクトの管理者によって、問題が処理される際に ステータスラベル が適用されます。
Status::Accepted: 問題が確認済み / 望ましい機能。
Status::進行中: 担当者が作業を開始します。
Status::Blocked: 進行には、フィードバックやその他のアクションが必要です。
Status::Rejected: レポートが無効または、望ましい機能ではありません。
Status::Fix uploaded: 修正リクエストがレビュー用に利用可能です
Status::Feedback-wanted: 解決策を決定するため、追加のフィードバックまたは回答が必要です
Status::Resolved: 問題が解決されたと判断され、議論が終了した場合、この問題はクローズされます。