Fornecer uma revisão de solicitação pull¶

Sempre ficamos felizes em receber avaliações de colaboradores, independentemente de seu nível de experiência.

Por que revisar as contribuições?¶

Todas as contribuições enviadas precisam ser revisadas, independentemente de terem sido enviadas por um membro da equipe principal ou por um colaborador de primeira viagem. Todos têm a possibilidade de deixar passar alguma coisa. O processo de revisão foi criado para oferecer uma rede de segurança adicional.

O objetivo do processo de revisão é garantir que todo o conteúdo, inclusive o código e a documentação, seja o mais livre de bugs e de fácil manutenção possível. Qualquer coisa que você possa fazer para promover esse objetivo é uma contribuição bem-vinda. Isso pode variar de algo simples, como corrigir um erro de digitação, a encontrar casos extremos no uso da API que não estão sendo detectados. Você pode identificar maneiras pelas quais o regime de testes poderia ser mais robusto ou sugerir maneiras de estruturar a arquitetura geral das alterações para que sejam mais fáceis de manter ou ampliar.

Posso revisar?¶

Sim! Você pode oferecer uma revisão em qualquer pull request que você veja aberta em BeeWare.

Como colaborador de primeira viagem, sinta-se à vontade para analisar qualquer pull request que encontrar, mesmo que tenha sido enviado por um membro da equipe principal. Se você for um novato, talvez esteja perdendo algum contexto maior do projeto, mas nosso objetivo é manter a base de código acessível independentemente do seu nível de experiência. Se houver algo no código que não faça sentido, isso pode indicar que há necessidade de mais documentação (seja no código ou como documentação de design autônoma).

Contribuir com uma revisão de pull request¶

Fornecer uma revisão de solicitação pull

Todos são bem-vindos para revisar qualquer contribuição para o projeto BeeWare. Há algumas considerações importantes que devem ser levadas em conta antes de começar.

PENSAR antes de revisar¶

Antes de se envolver em uma avaliação, PENSE. Como avaliadores, devemos considerar se a resposta que estamos prestes a enviar é..:

Verdadeiro. Sempre se esforce para fornecer sugestões e informações precisas.
Útil. Estamos fornecendo orientação sobre como melhorar o envio; essa orientação deve identificar claramente a origem de um problema ou de um caso de uso não considerado e, idealmente, fornecer um caminho a seguir para resolver ou satisfazer a preocupação.
Inspirador. Cabe a nós inspirar o autor a querer trabalhar com nossas alterações solicitadas.
Necessário. A expectativa é que o autor leia tudo o que postamos; devemos respeitar seu tempo e esforço postando somente quando necessário.
Gentil. Há várias maneiras de apresentar o mesmo feedback; precisamos garantir que estamos escolhendo ser gentis, solidários e construtivos com nossas palavras.

É perfeitamente possível PENSAR e, ao mesmo tempo, fazer uma avaliação eficaz. Os conceitos discutidos acima não impedem que você aponte quaisquer problemas que encontrar em um PR. Os colaboradores não terão a oportunidade de melhorar sua contribuição se não tiverem conhecimento das áreas que precisam ser aprimoradas. O importante é estar ciente de como você está apresentando esse feedback. Tente despersonalizar sua avaliação. Em vez de dizer: "Você cometeu um erro", você pode dizer: "Este código pode ser melhorado". Analise o código, não o autor.

É importante lembrar-se de fornecer feedback positivo, além de identificar as áreas que precisam ser aprimoradas. Se, por exemplo, as alterações forem especialmente úteis, fizerem algo particularmente inteligente ou você for apresentado a uma API que não conhecia, informe o autor! Nunca subestime o efeito de apontar algo que alguém fez corretamente ou bem, no meio de uma situação em que tudo o mais que você apontou são problemas que precisam ser resolvidos.

Sugestões de revisão do GitHub¶

A interface de revisão do GitHub tem um mecanismo para sugestões de alteração, no qual você pode fornecer a alteração exata que está sugerindo como uma substituição do conteúdo existente. Lembre-se de que, até que sejam aceitas e confirmadas, essas alterações sugeridas não passarão pelas verificações de pré-compromisso e de linting. Portanto, esse recurso deve ser usado para alterações menores, pois quanto maior for a alteração sugerida, maior será a probabilidade de ela introduzir problemas.