自定义用于分类通知的工作流

开始收件箱分类

在开始对收件箱进行分类之前，请先考虑您是更倾向于先查找并响应最重要的更新，还是先清除那些容易删除或分类的干扰性更新。

您可以根据通知的数量，在不同时间采用这两种方式的组合。

有关查找并响应最重要通知的示例工作流，请参阅检查最高优先级的通知。

有关删除易于删除或分类的通知的示例工作流，请参阅清理最不重要的通知。

选择哪些类型的通知最紧急需要审阅，并挑选一个最适合您的审阅时间。您可以思考“我阻塞了谁？”这个问题。

例如，您可以决定在每天的计划时间早上按以下顺序检查通知：

已请求您审阅的 Pull Request（使用过滤条件 reason:review-requested）
提及了您用户名的事件（也称为直接提及），使用过滤条件 reason:mention
提及了您所在团队的事件（也称为团队提及），使用过滤条件 reason:team-mention
特定仓库的 CI 工作流失败（使用过滤条件 reason:ci-activity 和 repo:owner/repo-name，并确保在通知设置中已为工作流失败启用了 CI 活动通知）

提示

要快速审阅最高优先级的通知，请按审阅优先级顺序设置自定义过滤器。更多信息，请参阅管理收件箱中的通知。

要进行通知跟进，您可以思考“我曾被阻塞的事项现在是否已经解除阻塞？”并选择跟进的通知优先级。

例如，您可以按以下顺序进行跟进：

您被指派的 Issue 和 Pull Request。立即关闭您可以处理的 Issue 或 Pull Request 并添加更新。必要时，将通知保存以便稍后审阅。
在已保存的收件箱中审阅通知，尤其是未读更新。如果线程已不再相关，请点击以将通知从已保存的收件箱中移除并取消保存。

在处理完高优先级通知后，审阅剩余的通知，例如参与的通知。请考虑以下问题：

您可以取消订阅此通知吗？此通知是否已完成并可以标记为Done？

提示

当您取消订阅通知后，除非再次参与该线程、被 @ 提及或您所在的团队被 @ 提及，否则不会收到新更新。当您将通知标记为Done时，该通知会从主收件箱视图中移除，可通过查询 is:read 查看。更多信息，请参阅管理收件箱中的通知。
您是否希望在此 Issue 或 Pull Request 被关闭、重新打开，或 Pull Request 被合并时收到后续更新？有关这些选项的更多信息，请参阅单个通知的分类。
您是否想要避免将来再收到此类通知？如果是，请考虑取消订阅。更多信息，请参阅管理 GitHub 上活动的订阅。

选择哪些类型的通知最容易且最快速地进行分类并从收件箱中删除，理想情况下一次处理多条通知。

例如，您可以决定按以下顺序清除通知：

有关一次同时管理收件箱中多条通知的更多信息，请参阅管理收件箱中的通知。

您也可以考虑更改通知设置或在可能的情况下取消订阅这些更新。更多信息，请参阅配置通知或管理 GitHub 上活动的订阅。