Best practices
Reducing noise
Use this page when HeyDeer posts comments your team doesn’t act on. The first rows change the most for the least effort.
Solutions
| Noise | What to change | Details |
|---|---|---|
| Too many findings you would not act on | Switch Feedback scope to Concise. To compare scopes first, preview them on a recent review in HeyDeer. | Feedback scope |
| Comments on generated code | Mark the files linguist-generated in .gitattributes on the base branch. | What HeyDeer reads |
| Reviews of bot or throwaway pull requests | Add automatic review filters, such as Author account Is none of Bot, or PR labels Is none of skip-review. | Automatic review filters |
| A finding you decided not to fix | Someone with write access explains the decision in its conversation or resolves the conversation, then comments @heydeer review. HeyDeer accepts the decision unless it has concrete evidence of a serious problem. | Declining a finding |
| A kind of comment nobody acts on | In review instructions, say what to leave alone, narrowly and with a reason. Avoid broad instructions such as “Don’t comment on performance”. | Review instructions |
| A repository check reporting on files it isn’t about | Narrow its files patterns and exclude tests or fixtures. | Repository checks |
| A review on every push | Keep Review only new changes on, and lower Maximum automatic reviews per PR or use Once per PR. Every automatic review uses credits, except free reviews of public repositories. | Automatic reviews |
| A long pull request conversation | Keep Resolve addressed HeyDeer conversations on. Or turn off Post review comments on the pull request, so the HeyDeer Review check carries the review; this also turns off automatic approval. | Publish results |