bug-triage

バグのトリアージ

範囲を定める

1. リポジトリの指示を読み、現在のブランチ、ステータス、関連する差分を確認します。
2. ユーザーが原因の調査のみを求めているのか、修正も許可しているのかを判断します。
3. 不足している情報を尋ねる前に、利用可能なエラー、ログ、テスト、コードを調べます。
4. 調査に影響する場合は、期待される動作、実際の動作、環境、発生頻度、最後に正常だった状態を記録します。

再現して切り分ける

1. 最小限かつ確実に再現できる手順を使います。元の失敗時の出力は保持します。
2. 失敗が断続的に起きる場合は、時間、乱数、並行処理、データ、再試行のうち一度に一つの変数を制御します。
3. 失敗する経路を端から端まで追跡します。編集前に、その関数またはコンポーネントを呼び出すすべての箇所を検索します。
4. 反証可能な仮説を立て、それを確認または棄却できる最も範囲の狭いチェックを実行します。
5. 回帰の境界を特定することで調査が大幅に短縮される場合に限り、履歴または git bisect を使います。

次の結果を明確に区別します。

• 製品の回帰が確認された
• 既存の問題、またはベースラインの失敗
• 環境、認証情報、サービス、または依存関係に起因する失敗
• 再現するには証拠が不十分

許可されている場合に修正する

1. 確認された原因で失敗する、最小限の回帰チェックを追加または調整します。
2. 目に見える一つの呼び出し元だけをガードするのではなく、共通の根本原因を修正します。
3. 無関係なリファクタリング、依存関係のアップグレード、フォーマットの変更、広範な例外処理は避けます。
4. 再現手順、対象を絞った回帰チェック、関連する最小限のプロジェクトチェックを再実行します。

リポジトリで既に選択されているパッケージマネージャー、ラッパー、コマンドを使います。リポジトリの指示、マニフェスト、ロックファイル、スクリプトから判断してください。ローカルにインストールされているという理由だけで、別のツールに置き換えてはいけません。

報告する

以下を含めます。

• 確認事項： 正確な症状と影響範囲。
• 根本原因： 確認済みの説明、または有力な仮説であることを明示した説明。
• 変更内容： 変更したファイルと動作、または diagnosis only。
• 検証： ベースラインの失敗を含む、実行したコマンドと結果。
• 残るリスク： 未テストの経路、不安定な動作、または外部要因による阻害。

ユーザーが再利用可能な受付フォームを必要としている場合に限り、references/bug-report-template.md を使用します。