PRs fáceis de revisar

Mantenha cada pull request focado

Um pull request que faz uma coisa recebe problemas encontrados sobre essa coisa. Separe refatorações, renomeações e movimentações de arquivos das mudanças de comportamento, pois elas escondem as linhas que realmente mudaram.

Descreva a intenção e vincule a issue

O HeyDeer lê o título e a descrição. Diga para que serve a alteração, a parte sobre a qual você tem menos certeza e o que deixou de fora de propósito. Quando o autor tem acesso de escrita, uma concessão declarada, como “Novas tentativas estão fora do escopo; acompanhado em #412”, conta como uma decisão, assim como recusar um problema encontrado.

Vincule também a issue. Com Ler issues vinculadas ativado, como vem por padrão, o HeyDeer pode lê-la para conhecer os requisitos que a alteração deve atender. Consulte O que o HeyDeer lê.

Marque os arquivos gerados

Marque o código gerado com linguist-generated no .gitattributes, e o HeyDeer o deixa de fora. O HeyDeer lê o atributo da branch base, então faça essa alteração primeiro em um pull request próprio.

Abra um rascunho enquanto itera

As revisões automáticas ignoram rascunhos por padrão e consideram o pull request quando você o marca como pronto para revisão. Para um feedback antecipado, comente @heydeer review no rascunho. Consulte Filtros de revisão.

Envie correções como novos commits

As revisões de acompanhamento analisam o que mudou desde a última revisão, o que funciona melhor quando as correções chegam como novos commits. Fazer merge da branch de destino ou rebase sobre ela não tem problema. Envie correções relacionadas juntas para usar menos revisões automáticas. Consulte Revisões de acompanhamento.

Responda aos problemas encontrados que você recusar

Responda na conversa com o motivo, não apenas “não vou corrigir”, ou resolva a conversa. Uma decisão de alguém com acesso de escrita diz ao HeyDeer para não levantar o problema de novo. Consulte Como reduzir o ruído.