Pedidos Pull – MRTK2

Pré-requisitos

Se ainda não contribuiu para um projeto da Microsoft, poderá ser-lhe pedido para assinar um contrato de licença de contribuição. Um comentário no PR irá informá-lo se o fizer.

Importante

Se for um funcionário da Microsoft e não for membro da organização Microsoft no GitHub, ligue as suas contas Microsoft e GitHub à corpnet ao visitar o Open Source na Microsoft antes de iniciar o seu pedido Pull. Existem alguns processos que terá de fazer com antecedência.

Criar um pedido Pull

Quando estiver pronto para submeter um pedido Pull, crie um pedido Pull direcionado para o ramo principal . Para correções de erros durante um período de estabilização de versão, procure o ramo mais recente prerelease/* . As novas funcionalidades devem sempre entrar em main.

Leia as diretrizes e certifique-se de que o pedido Pull cumpre as diretrizes.

• Certifique-se de que faz referência a qualquer Problema/Pedido de Funcionalidade ou Tarefa à qual o PR se relaciona.
• Verifique se o pedido Pull contém apenas ficheiros/alterações relacionadas com o PR.
• Verifique se a documentação está atualizada e incluída. Verifique se todos os campos públicos têm comentários.
• Se adicionar uma nova funcionalidade, verifique se os testes estão incluídos para validar a funcionalidade (veja UnitTests).
• Se corrigir um erro, escreva um teste para verificar a correção de erros.

Os responsáveis pela manutenção do projeto irão rever as alterações. Pretendemos rever todas as alterações no prazo de três dias úteis. Aborde quaisquer comentários de revisão, envie para o seu ramo de tópico e publique um comentário informando-nos de que existem novos conteúdos a rever.

Nota

Todos os PR submetidos ao projeto também serão verificados de acordo com o guia de normas de codificação do MRTK, por isso, reveja-os antes de submeter o seu PEDIDO para garantir um processo suave.

Diretrizes de pedidos Pull

Estas diretrizes baseiam-se nas práticas de engenharia da Google.

Manter pedidos Pull pequenos

Os PRs mais pequenos são revistos de forma mais rápida e minuciosa, são menos propensos a introduzir erros, mais fáceis de reverter e mais fáceis de intercalar.

Os pedidos Pull devem ser pequenos o suficiente para que um engenheiro possa revê-lo em menos de 30 minutos. Tente fazer uma alteração mínima que endereça apenas uma coisa. Se tiver de criar um PR grande, divida-o em vários PRs que entram no seu ramo local ou num ramo de funcionalidade do MRTK. Evite adicionar novos recursos (por exemplo, fbx, ficheiros obj) e, em vez disso, tente reutilizar recursos existentes.

Os testes devem ser adicionados no mesmo PR que a sua correção/funcionalidade, exceto para emergências

Os testes são a melhor forma de garantir que as alterações não regredem o código existente, mas também é fácil esquecer os testes ao submeter pedidos Pull. Exigir que eles entrem com o seu PR são uma ótima forma de garantir que os testes são escritos.

Todas as funcionalidades e correções de erros devem ter testes associados. Se não tiver a experiência ou o tempo necessário para escrever um teste, crie um problema para escrever os testes e marque-os com a etiqueta Considerar para Iteração Atual.

A documentação deve ser adicionada no mesmo pedido Pull que uma correção/funcionalidade

A maioria dos programadores analisa primeiro a documentação, não o código, quando compreende como utilizar uma funcionalidade. Garantir que a documentação está atualizada torna muito mais fácil para as pessoas consumirem e confiarem no MRTK. A documentação deve ser sempre agrupada com a solicitação relacionada para garantir que os itens permanecem atualizados e consistentes.

Certifique-se de que cada campo público, método, propriedade tem comentários de resumo de barra tripla para que o nosso site docfx possa gerar descrições para campos/métodos. Se necessário, atualize os ficheiros markdown na pasta Documentação.

As descrições dos pedidos Pull devem descrever de forma clara e completa as alterações

Descrições claras e completas dos pedidos Pull garantem que os revisores compreendem o que estão a rever.

Se adicionar funcionalidades que contêm UX, adicione uma imagem/gif da funcionalidade que está a alterar. Eis um bom exemplo. Outra sugestão é ter um gif de Antes e Depois, por exemplo, neste pedido Pull. Uma ferramenta que recomendamos para gerar gifs a partir de capturas de ecrã é ScreenToGif.