通知をトリアージするためのワークフローをカスタマイズする

インボックスのトリアージを開始する

インボックスのトリアージを開始する前に、最重要の更新を最初に見つけて対応するか、削除またはトリアージが簡単な煩わしい更新をインボックスからクリアするかを検討してください。

通知の量に応じて、さまざまな時点で両方のアプローチを組み合わせて使用することを決定できます。

最も重要な通知を検索して応答するワークフローの例については、「最も優先度の高い通知を確認する」を参照してください。

簡単に削除またはトリアージできる通知を削除するワークフローの例については、「最も重要度の低い通知を消去する」を参照してください。

一番最初に確認する通知の種類を選択し、通知の確認時間を選択します。「誰をブロックするか」ということを検討します。

たとえば、毎日の計画を行う午前中に、次の順序で通知を確認できます。

レビューがリクエストされているプルリクエスト（reason:review-requestedでフィルタリング）
ユーザー名@mentionedに関連するイベント、直接メンションとも呼ばれます（reason:mentionでフィルタリング)
あなたがメンバーであるチームが@mentionedされるイベント、チームメンションとも呼ばれます（reason:team-mentionでフィルタリング）
特定のリポジトリに対するCIワークフローの失敗(reason:ci-activity と repo:owner/repo-name でフィルターし、通知設定でワークフローエラーの CI アクティビティ通知を有効にしていることを確実にします)

ヒント

最も優先度の高いものをすばやく確認するには、確認している優先度の順にカスタムフィルターを設定します。詳しくは、「インボックスからの通知を管理する」をご覧ください。

通知をフォローアップする際には、「以前ブロックされていたが、現在はブロックされていないものは何か？」という質問を考慮してみてください。フォローアップ通知の優先順位を選択します。

たとえば、次の順序でフォローアップすることを決定できます。

あなたに割り当てられている Issue およびプルリクエスト。可能な限りすぐに問題やプルリクエストをクローズして、更新しましょう。必要に応じて、後で確認するために通知を保存します。
保存済インボックスの通知、特に未読の更新を確認します。スレッドが関連しなくなった場合、をクリックし、保存したインボックスから通知を削除して保存を解除します。

優先度の高い通知をトリアージした後、参加通知などの残りの通知を確認します。次の質問を考慮してください。

この通知をサブスクライブ解除できますか？この通知は完了し、完了としてマークする準備ができましたか?

ヒント

通知の登録を解除すると、スレッドに参加するか、自分が@mentionedであるか、または所属しているチームが@mentionedでない限り、新しい更新を受け取ることはありません。通知を完了としてマークすると、通知はメインのインボックスビューから削除され、is:read クエリで表示できます。詳しくは、「インボックスからの通知を管理する」をご覧ください。
この Issue やプルリクエストがクローズまたは再オープンされたとき、またはプルリクエストがマージされたときに、今後も更新を受け取りますか？これらのオプションについて詳しくは、「単一の通知をトリアージする」を参照してください。
今後このような通知を受け取らないようにしますか？その場合は、サブスクライブ解除を検討してください。詳しくは、「GitHubでのアクティビティのサブスクリプションの管理」をご覧ください。

トリアージしてインボックスから削除する際に最も速くて簡単な通知の種類を選択します。理想的としては、一度に複数の通知をトリアージします。

たとえば、次の順序で通知をクリアすることができます。

受信トレイ内の複数の通知を同時に管理する方法の詳細については、「インボックスからの通知を管理する」を参照してください。

可能な場合、通知設定を変更するか、これらの更新のサブスクライブ解除することを検討することもできます。詳細については、「通知を設定する」または「GitHubでのアクティビティのサブスクリプションの管理」を参照してください。