---

22.15 Revendo o trabalho de outros

Perhaps the biggest action you can do to help GNU Guix grow as a project is to review the work contributed by others. You do not need to be a committer to do so; applying, reading the source, building, linting and running other people’s series and sharing your comments about your experience will give some confidence to committers. You must ensure the check list found in the Enviando patches section has been correctly followed. A reviewed patch series should give the best chances for the proposed change to be merged faster, so if a change you would like to see merged hasn’t yet been reviewed, this is the most appropriate thing to do! If you would like to review changes in a specific area and to receive notifications for incoming patches relevant to that domain, consider joining the relevant team(s) (veja Equipes).

Comentários de revisão devem ser inequívocos; seja o mais claro e explícito possível sobre o que você acha que deve ser alterado, garantindo que o autor possa tomar medidas sobre isso. Tente manter as seguintes diretrizes em mente durante a revisão:

1. Seja claro e explícito sobre as mudanças que você está sugerindo, garantindo que o autor possa agir sobre isso. Em particular, é uma boa ideia pedir explicitamente por novas revisões quando você quiser.
2. Mantenha o foco: não altere o escopo do trabalho que está sendo revisado. Por exemplo, se a contribuição aborda um código que segue um padrão considerado difícil de manejar, seria injusto pedir ao remetente para corrigir todas as ocorrências desse padrão no código; para simplificar, se um problema não relacionado ao patch em questão já estava lá, não peça ao remetente para corrigi-lo.
3. Garantir o progresso. Conforme respondem à revisão, os remetentes podem enviar novas revisões de suas alterações; evite solicitar alterações que você não solicitou na rodada anterior de comentários. No geral, o remetente deve ter uma noção clara do progresso; o número de itens abertos para discussão deve diminuir claramente ao longo do tempo.
4. Aim for finalization. Revisar código consome tempo. Seu objetivo como revisor é colocar o processo em um caminho claro em direção à integração, possivelmente com mudanças acordadas, ou rejeição, com um raciocínio claro e mutuamente compreendido. Evite deixar o processo de revisão em um estado persistente sem uma saída clara.
5. Review is a discussion. The submitter’s and reviewer’s views on how to achieve a particular change may not always be aligned. To lead the discussion, remain focused, ensure progress and aim for finalization, spending time proportional to the stakes⁵¹. As a reviewer, try hard to explain the rationale for suggestions you make, and to understand and take into account the submitter’s motivation for doing things in a certain way. In other words, build consensus with everyone involved (veja Making Decisions).

Quando você considera a alteração proposta adequada e pronta para inclusão no Guix, a seguinte linha bem compreendida/codificada ‘Reviewed-by: Your Name <your-email@example.com>’ ⁵² deve ser usada para assinar como revisor, o que significa que você revisou a alteração e que ela parece boa para você:

• Se a série toda (contendo vários commits) parecer boa para você, responda com ‘Reviewed-by: Your Name <your-email@example.com>’ para a página de capa, se houver uma, ou para o último patch da série, caso contrário, adicionando outro comentário ‘(para toda a série)’ na linha abaixo para explicitar esse fato.
• Se você quiser marcar um único commit como revisado (mas não a série inteira), basta responder com ‘Reviewed-by: Your Name <your-email@example.com>’ para essa mensagem de commit.

Se você não for um colaborador, pode ajudar outras pessoas a encontrar uma série que você revisou mais facilmente adicionando uma usertag reviewed-looks-good para o usuário guix (veja Debbugs Marcadores de usuário).