Recebendo uma revisão de solicitação de pull

Seu pull request foi enviado e aprovado pelo CI. Agora ela está pronta para ser revisada.

tl;dr - O processo de revisão

A versão resumida do processo de revisão:

1. Aguarde uma revisão.
2. Responda ao feedback.
3. Se forem solicitadas alterações:
4. Trabalhe para concluir as alterações solicitadas.
5. Envie todas as alterações solicitadas.
6. Solicite novamente uma revisão quando todas as alterações solicitadas tiverem sido enviadas.
7. Repita a seção três até que não sejam necessárias mais alterações.
8. Aguarde a aprovação e o merge de sua pull request.

Parabéns! Você acabou de fazer uma contribuição para BeeWare!

Enviei minha solicitação pull, o que vem a seguir?

Depois de enviar sua pull request, você precisará aguardar a revisão da sua contribuição. Há dois lados no processo de revisão: fornecer uma revisão e receber uma revisão.

Revisar as expectativas

Você deve esperar que todas as pessoas que analisarem seus envios sigam essas diretrizes, inclusive as avaliações dos membros da equipe principal. Você também deve seguir essas diretrizes quando estiver analisando os envios de outras pessoas.

Se achar que o seu revisor está se desviando dessas expectativas e se sentir à vontade para levantar o problema no pull request, você pode fazer isso. Se não se sentir confortável, entre em contato com a Equipe de Resposta ao Código de Conduta do BeeWare. Analisaremos seu relatório e faremos o acompanhamento com seu revisor. O acompanhamento refletirá a ação relatada; uma transgressão menor pode resultar em uma discussão, enquanto uma violação maior pode resultar em algo mais sério.

Fornecimento de uma revisão

Todos são bem-vindos para fazer uma revisão em qualquer pull request. Estas diretrizes descrevem nossas expectativas em relação a uma revisão, independentemente de ela ser fornecida por um membro da equipe principal ou por um membro da comunidade.

Um membro da equipe principal sempre precisará fazer a revisão final, mas as revisões dos membros da comunidade podem ser uma maneira útil de agilizar o processo - idealmente, a revisão da equipe principal seria uma formalidade após as revisões da comunidade terem identificado todos os principais problemas.

Recebimento de uma avaliação

O recebimento de uma revisão envolve três etapas básicas:

1. Feedback e perguntas iniciais.
2. Solicitações de alteração.
3. Aprovação e fusão.

Cada etapa está detalhada abaixo. Se em algum momento do processo você tiver dúvidas, não hesite em perguntar! Ficaremos felizes em ajudar.

Cronograma e feedback inicial

A equipe principal tem como objetivo garantir que todas as solicitações pull recebam uma revisão dentro de dez dias úteis. No entanto, com envios mais complicados, ou quando uma pull request é enviada quando parte da equipe está de licença, esse prazo pode ser estendido.

Normalmente, mantemos a continuidade com os revisores em cada pull request, ou seja, você provavelmente trabalhará com o mesmo revisor durante toda a revisão. Isso significa que o revisor terá contexto durante todo o processo e você poderá saber o que esperar em termos de cadência de resposta e estilo de revisão. Se o revisor inicial identificar que não tem o conhecimento necessário para revisar suas pull requests, ou se souber que não estará disponível por algum motivo, ele poderá passar a responsabilidade pela sua pull request para outro membro da equipe.

Você pode esperar que respondamos a cada troca dentro de um prazo contínuo de dez dias úteis. Responder a comentários e perguntas é uma parte essencial do processo de avaliação. Esperamos uma resposta sua antes de passarmos para a próxima etapa do processo.

Solicitações de alteração

Na maioria das vezes, o revisor solicitará alterações em sua solicitação pull. Isso não é necessariamente um reflexo de seu trabalho, é simplesmente parte do processo.

Se a revisão inicial revelar um número significativo de problemas, a primeira revisão poderá não ser abrangente. Em vez disso, ela se concentrará em fornecer orientação de alto nível sobre o trabalho necessário para colocar o pull request em um estado mesclável. O processo de revisão pode incluir perguntas para esclarecer a finalidade e o escopo do trabalho que foi tentado.

Trabalhar com as alterações solicitadas

Seu revisor publicará comentários em seu pull request. Esses comentários podem ser gerais, em um arquivo específico ou em uma linha ou linhas específicas de código. Às vezes, eles incluirão alterações sugeridas diretamente que você pode aplicar à sua pull request por meio da interface do usuário do GitHub. Normalmente, eles são perguntas, solicitações de esclarecimento ou orientações sobre atualizações.

Marcando uma conversa como resolvida

Durante a parte de discussão do processo de feedback, você nunca deve marcar uma conversa iniciada pelo seu revisor como "resolvida". Marcar a conversa como resolvida é responsabilidade do revisor. Cabe a ele determinar se o problema identificado foi resolvido.

Se a revisão revelar um problema sistemático (por exemplo, uma inconsistência de nomenclatura existente no código), o revisor poderá não destacar todas as instâncias desse problema. Em vez disso, ele pode escolher alguns exemplos do problema e indicar que outras instâncias também devem ser corrigidas. Se uma revisão destacar um problema em um local e você achar que ele pode se aplicar a outro, corrija esse problema onde quer que ele ocorra. Se não tiver certeza, peça esclarecimentos ao revisor.

Enviar todas as alterações solicitadas

Depois de fazer todas as alterações solicitadas, você pode enviar uma atualização para a sua solicitação pull. Isso acionará uma nova execução de CI; depois de confirmar que a CI ainda está passando, publique um comentário solicitando uma revisão atualizada e a equipe principal analisará novamente a sua solicitação pull.

Envie, não force nem rebase

Quando você estiver atualizando sua pull request durante uma revisão, é importante deixar o histórico de commits intacto. Não importa se há uma lista enorme de commits; todos eles são esmagados quando fazemos o merge da pull request. Se você forçar o push ou rebase da sua pull request no meio de uma revisão, poderá estar removendo um contexto importante necessário para o revisor.

Solicite novamente uma avaliação

Depois de resolver todas as alterações solicitadas em uma determinada revisão e o CI for aprovado novamente, você poderá solicitar novamente uma revisão ao seu revisor. Se um problema for particularmente complicado e a correção de uma coisa afetar outra, você poderá solicitar uma revisão da parte específica que atualizou. O pressuposto é que qualquer solicitação de revisão é uma solicitação de revisão completa. Se você não estiver pronto para uma revisão completa, certifique-se de especificar exatamente o que está procurando.

Aprovação e mesclagem de solicitações pull

Depois que você responder a todas as solicitações de alteração, a pull request será aprovada. Na maioria dos casos, quando uma pull request é aprovada, nós a mesclamos imediatamente. Em alguns casos, pode haver circunstâncias atenuantes, como depender de outra pull request ainda não mesclada, que levará a um atraso. Comunicaremos isso nos comentários, para que você saiba a situação.