triage-issue-reports

イシューレポートをトリアージする

Slack の報告を1件分類し、元スレッドに役立つ判定を1件投稿します。明確な新規バグの場合に限り、トラッカーにイシューを作成してください。ここでは再現や修正を行わないでください。

自動化から提供された外部の Benny 設定を読み込みます。設定がない、不正な形式、または不完全な場合は、投稿もトラッカーへの書き込みも行わずに停止してください。

厳守する安全ルール

• 元チャンネルとルートスレッドの座標は変更できません。
• 元チャンネルにルートメッセージを投稿してはいけません。
• 別のチャンネルへの投稿、返信のブロードキャスト、DM の送信、代替スレッドの開始を行ってはいけません。
• トラッカーに書き込む前、および判定を投稿する直前に、元スレッドの親メッセージを事前確認してください。
• 親メッセージが見つからない、削除されている、アクセスできない、または状態が不確かな場合は、何も書き込まずに停止してください。
• 内容のある判定を1件投稿してください。進捗を説明してはいけません。
• Slack に投稿できるのはコーディネーターだけです。
• 委任されたワーカーが返すのは調査結果のみです。読み取り専用とし、Slack 認証情報や書き込み操作を渡してはいけません。
• すべての子プロンプトで、SendSlackMessage、PostToSlack、chat.postMessage、およびその他すべての Slack への書き込みを禁止してください。
• ワーカーの隔離でこれらの制限を強制できない場合は、コーディネーター自身が作業してください。
• 元スレッドにリンクできないイシューを作成してはいけません。
• 推測や重複の可能性があるイシューより、チケットを作成しないことを優先してください。
• 元の座標には pstack の principle-separate-before-serializing-shared-state を適用してください。
• 最終判定には pstack の principle-minimize-reader-load と unslop スキルを適用してください。

1. 元の座標を固定する

作業リストの作成や委任の前に、次の手順を実行してください。

1. トリガーから source_channel_id を読み取ります。
2. 設定済みの元チャンネルと一致することを確認します。
3. trigger.thread_ts がある場合はその値を、ない場合は trigger.ts を SOURCE_THREAD_TS に設定します。
4. SOURCE_THREAD_TS が空でないことを確認します。
5. SOURCE_CHANNEL_ID と SOURCE_THREAD_TS を変更不可の値として保存します。
6. スレッドを読み、ルートの座標がその値と完全に一致することを確認します。
7. 安定した元メッセージのパーマリンクを取得します。

以降の元メッセージの読み取りと投稿には、必ず保存した値を使用してください。返信のタイムスタンプや運用スレッドのタイムスタンプで置き換えてはいけません。

2. 報告全体を読む

判断する前に、ルートメッセージと現在の返信を読みます。

次の情報を記録してください。

• 報告者の文言
• 該当する場合は、製品のバージョン、アプリのビルド、環境、プラットフォーム
• 期待される動作
• 実際に確認された動作
• 発生頻度と発生条件
• エラーテキストまたはスタックの特徴
• 既存のイシュー、コミット、プルリクエストへのリンク
• すでに誰かが修正中であるという明示的な記述

関連する添付ファイルをすべて確認してください。

• スクリーンショットは、内容を十分確認できる解像度で読み取ります。
• 動画は、正常な動作と不具合のある動作を分ける状態遷移を確認します。
• ログ、トレース、クラッシュのテキストから、具体的な特徴を読み取ります。
• メディアの確認に専門的な作業が必要な場合は、読み取り専用のメディアワーカーを使い、質問を限定してください。ワーカーが返すのは調査結果のみです。
• 添付ファイルを読み取れない場合は、判定でその旨を述べてください。内容を捏造してはいけません。

報告者に追加情報を尋ねる前に、スレッド内の既存の証拠を確認してください。

3. 担当先を決める前に原因をたどる

担当者や対応先を選ぶ前に、範囲を限定してソースコードと履歴を調査してください。報告された操作から確認された結果までの経路をたどるには、pstack の how スキルを使います。報告がリグレッションのように見える場合や、防御的なコードに関係する場合は why を使います。

1. 報告された操作から確認された結果までの、可能性の高いコードパスを特定します。
2. 表面化している症状がそのコードパスに属するのか、下位の依存関係に属するのかを確認します。
3. 報告がリグレッションのように見える場合は、最近の変更を確認します。
4. 同じ症状に対応するマージ済みコミットやオープン中のプルリクエストがないか確認します。
5. 確認できた事実と仮説を分けます。

根本原因を完全に特定する必要はありません。表面化している症状を誤った担当者に割り当てないために十分な調査を行ってください。

リポジトリを読み取れない場合は、コードの担当者を推測してはいけません。慎重に分類し、原因をたどれなかったことを伝えてください。

4. 分類する

カテゴリーを1つ選んでください。

バグ

意図された動作に反しています。たとえば、誤った出力、状態の破損、エラー、クラッシュ、ハング、何も起きない、またはリグレッションなどです。

パフォーマンス

報告には、測定可能な処理の遅さ、メモリの過剰消費、バッテリーの消耗、カクつき、その他のリソース問題が記載されています。バグとして扱いますが、測定値やプロファイルはそのまま維持してください。

機能リクエスト

現在の動作は意図されたものと見られ、報告者は別の動作や機能を望んでいます。

質問またはフィードバック

何かの仕組みについて質問している、具体的な不具合を挙げずに好みを述べている、または一般的なフィードバックを伝えています。

振り分け先の変更

原因の追跡により、別の設定済みの振り分け先がその問題を担当していることが判明しています。

バグか機能リクエストか判断がつかない場合は、起票しないでください。判定では、焦点を絞った質問を1つだけ行い、other マーカーを使用してもかまいません。

5. 設定済みの振り分けを適用する

routing.map_path から任意の振り分けマップを読み込みます。

• 確認済みの製品領域、コードパス、またはエラーシグネチャに基づいて照合します。
• 原因の追跡で別の箇所が原因と判明している場合、目に見える症状だけでは不十分です。
• 該当する振り分け先がない場合は、担当者が不明であると伝えてください。推測してはいけません。
• クロスポストはしないでください。元のスレッドで、報告者にどこへ問題を報告すべきか伝えてください。

担当者への通知はデフォルトで無効です。以下の条件をすべて満たす場合に限り、通知が許可されます。

1. 振り分けマップに担当者が明示されている。
2. 設定でその種類の通知が許可されている。
3. 担当者の意見が必要な機能リクエストである、または最近の履歴から、強い根拠に基づいてリグレッションを起こした可能性の高い人物が特定されている。
4. 担当者が広範なオンコールグループではない。

これ以外の場合は通知しません。

6. イシュートラッカーアダプターを使用する

トラッカーはアダプターであり、特定のベンダーは必須ではありません。Linear アダプターは有効な例の1つです。GitHub Issues アダプターや他のトラッカーも、同じ契約を実装できます。

設定済みのアダプターは、以下を提供する必要があります。

• テキスト、状態、ラベル、ソース URL、日付範囲によるイシューの検索
• 1件のイシューとそのリンクの読み取り
• タイトル、本文、ステータス、ラベル、ソース URL を指定したイシューの作成
• 無関係なフィールドを置き換えずに既存のイシューを更新
• ソースリンクと再発に関するメモの追加
• Slack への引き継ぎに失敗した場合に、この実行で作成したイシューのキャンセル、クローズ、または削除

必須の操作を利用できない場合、その書き込みはフェイルクローズしてください。

設定済みのチーム、プロジェクト、ステータス、ラベルは実行時に解決してください。設定で明示的に要求されていない限り、ID を作り上げたり、ラベルを作成したり、担当者を割り当てたり、優先度を設定したりしないでください。

7. 重複排除

このソースのパーマリンクが、すでにトラッカーのイシューまたは過去のトリアージ返信にリンクされているか、必ず確認してください。リンクされている場合は、重複投稿や重複作成をしないでください。

バグやパフォーマンスの報告については、以下を使ってトラッカーを検索してください。

• 正確なエラーまたはクラッシュのシグネチャ
• 製品領域
• 発生条件
• 症状
• バージョンまたは日付範囲
• リグレッションが疑われるコミット
• ソースのパーマリンク

以下から1つの結果を選択してください。

• 重複と確信できる：同じシグネチャ、または同じ領域・発生条件・症状、または共通の原因が確認済み。
• 関連の可能性あり：共通の原因が考えられるものの、証明されていない。
• 類似性は低い：表面的な類似にすぎない。
• 該当なし。

重複と確信できる場合は、既存のイシューを更新して、ソースのパーマリンクと短い再発メモを追加してください。設定で指示されていない限り、再オープン、ラベルの変更、担当者の再割り当てはしないでください。

該当する可能性のあるイシューがある場合は、判定で不確実なものとしてリンクし、新たなイシューは作成しないでください。

長期間クローズされているイシューは、リグレッションの手掛かりであり、自動的に現在進行中の重複として扱うものではありません。

8. 作成するかどうかを判断する

次のすべてに当てはまる場合にのみ作成します。

1. 分類が bug または performance である。
2. 動作が明らかに壊れている。
3. 問題がまだ有効である、または修正済みとして知られていない。
4. 重複排除で、確信のある、または妥当な有効な一致が見つからなかった。
5. ソース親とパーマリンクがプリフライトを通過した。
6. トラッカーのターゲットフィールドが解決された。
7. 判定の投稿が失敗した場合に、アダプターが補償できる。

機能リクエスト、質問、フィードバック項目、 reroute、重複の可能性、確信のある重複、または修正済みの問題については決して作成しないでください。

新しい issue は自己完結していなければなりません。

• 領域と症状を示す簡潔なタイトル
• 報告者の引用
• 期待される動作と観察された動作
• バージョンと環境、または unknown
• トリガーと頻度
• ソーススレッドのパーマリンク
• 仮説としてラベル付けされた仮説を含む、原因追跡の短い調査結果
• サポートされている場合はインラインのスクリーンショットまたは代表的な動画フレーム
• 残りの成果物へのリンク
• 設定された intake ステータスとラベル

推測された根本原因をタイトルに入れないでください。

9. 判定を 1 つ投稿する

新しいソース親のプリフライトを実行します。次に、channel=SOURCE_CHANNEL_ID と thread_ts=SOURCE_THREAD_TS を指定して、返信をちょうど 1 つ投稿します。

空でない thread_ts なしに、ソースチャンネルへの投稿アクションを呼び出さないでください。

返信は短く保ってください。

• 結果を最初に述べる。
• 既存または新規のトラッカー issue がある場合はリンクする。
• 必要に応じて reroute または不足している事実を 1 つ言及する。
• 許可されたオーナーへの ping を最大 1 つ含める。
• ちょうど 1 つのマーカー行で終える。

マーカーの契約:

[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]

設定されたマーカー文字列のみを使用してください。repro 自動化がマーカーを信頼するのは、このソーススレッド内の設定されたトリアージ ID から来た場合のみです。

投稿後、同じソーススレッドを読み、SOURCE_THREAD_TS の下に判定が表示されることを確認します。表示されない場合は、ルートで再試行しないでください。

この実行でトラッカー issue を作成し、判定が反映されなかった場合は、アダプターの補償アクションを使用します。issue がキャンセル、クローズ、または削除されていることを確認します。補償を確認できない場合は、自動化の実行出力でのみ失敗を報告してください。

10. フォローアップウィンドウを 1 つ監視する

設定されたフォローアップウィンドウの間、ソーススレッドを監視し、その後停止します。

• トリアージ ID への直接の質問にのみ回答する。
• 安全な場合は、トラッカー issue に具体的な修正を適用する。
• 同じ実行で 2 つ目のマーカーを出さない。
• 人間の調整や雑談には関与しない。
• 誰かが自動化の停止を求めた場合は早期に停止する。

ウィンドウを 1 回を超えて延長しないでください。新しい報告は新しい実行を開始する必要があります。