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

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

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

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

最も重要な通知を見つけて対応するワークフローの例については、「最優先の通知を確認する」を参照してく� さい。

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

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

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

レビューがリクエストされているプルリクエスト。 (reason:review-requested でフィルタ)
ユーザ名が@メンション（直接メンション）されているイベント。 (reason:mention でフィルタ)
メンバーになっている Team が@メンション（Team メンション）されているイベント。 (reason:team-mention でフィルタ)
特定のリポジトリの CI ワークフローエラー。（reason:ci-activity および repo:owner/repo-name でフィルタ。通知設定でワークフローエラーの CI アクティビティ通知が有効になっていることを確認してく� さい）

ヒント: 最も優先度の高いものをすばやく確認するには、確認している優先度の� �にカスタ� フィルタを設定します。詳しい情� �については「インボックスからの通知を管理する」を参照してく� さい。

通知をフォローアップするには、「今はブロックされていないが、ブロックされていたもの」ということを検討します。フォローアップ通知の優先� �位を選択します。

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

割り当てられた Issue およびプルリクエスト。可能な Issue またはプルリクエストをすぐにクローズして、更新を追� します。必要に応じて、後で確認するために通知を保存します。
保存済インボックスの通知、特に未読の更新を確認します。 If the thread is no longer relevant, deselect to remove the notification from the saved inbox and unsave it.

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

この通知をサブスクライブ解除できますか？この通知は完了していて、Doneとしてマークしても大丈夫ですか？

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

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

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

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

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