最佳实践
减少噪音
当 HeyDeer 发布了团队不会去处理的评论时，请参考本页。表格中靠前的几行，花最少的精力就能带来最大的改善。
解决方法
| 噪音 | 如何调整 | 详情 |
|---|---|---|
| 你不会处理的问题太多 | 将反馈范围切换为精简。如需先比较不同范围，可在 HeyDeer 中最近的一次审查上预览。 | 反馈范围 |
| 对生成代码的评论 | 在目标分支的 .gitattributes 中将这些文件标记为 linguist-generated。 | HeyDeer 读取的内容 |
| 对机器人或临时 PR 的审查 | 添加自动审查筛选条件，例如作者账号类型 → 不是以下任意一项 → 机器人，或 PR 标签 → 不是以下任意一项 → skip-review。 | 自动审查筛选条件 |
| 你决定不修复的问题 | 由有写权限的人在该问题的讨论中说明决定，或将讨论标记为已解决，然后评论 @heydeer review。除非有具体证据表明存在严重问题，否则 HeyDeer 会接受这个决定。 | 决定不处理发现的问题 |
| 某类没人处理的评论 | 在审查指令中说明哪些内容不必理会，范围要窄，并给出理由。避免“不要评论性能”这类宽泛的指令。 | 审查指令 |
| 仓库检查在与其无关的文件上报告问题 | 缩小其 files 模式，并排除测试或测试夹具。 | 仓库检查 |
| 每次推送都触发审查 | 保持只审查新改动开启，并调低每个 PR 的自动审查次数上限，或改用每个 PR 审查一次。除公开仓库的免费审查外，每次自动审查都会消耗积分。 | 自动审查 |
| PR 讨论过长 | 保持将已处理的 HeyDeer 讨论标记为已解决开启。也可以关闭在 PR 中发布审查评论，只在 HeyDeer Review 检查中显示审查结果；这也会关闭自动批准。 | 发布结果 |