As solicitações de envio são como o sangue de um repositório. Eles mantêm tudo saudável e em movimento. Esta página detalha como criar um PR completo e fácil de analisar, o que aumenta a probabilidade de uma RP ser mesclada.
Aqui estão as etapas que você pode seguir para criar o melhor RP possível.
- Comunicação
- Configuração
- Mantenha o tamanho pequeno
- Mantenha a limpeza
- Teste sua mudança
- Comunicação (pt2)
Comunicação
Antes de começar a escrever código, é útil se comunicar com a equipe principal para que eles saibam seus interesses.
Se houver um problema no qual você esteja interessado, coloque um comentário sobre ele dizendo que você vai começar a trabalhar nele. Isso garante que não haja várias pessoas trabalhando na mesma coisa. Um membro da equipe responderá para confirmar que é seu.
Se você tiver uma ideia que não foi abordada por problema, escreva um antes de começar o trabalho. Isso dá à equipe a chance de discutir a melhor forma de criar a mudança antes de começar a criar, o que economiza seu trabalho a longo prazo.
Começar a configuração
Se esta é sua primeira contribuição com o Blockly ou as amostras em bloco, comece na página de configuração de desenvolvimento.
Mantenha-o pequeno
Tente sempre manter suas mudanças pequenas e focadas. Preferimos analisar vários PRs menores do que analisar um PR gigante. Algumas boas regras de ouro são:
- Corrigir um problema. Não tente resolver vários problemas de uma vez só.
- Limitar o escopo. Normalmente, uma RP leva menos de 8 horas, dependendo da sua familiaridade com a base de código.
- Use confirmações. Se sua RP parece um pouco grande, divida as alterações em grupos lógicos usando confirmações do git.
Mantenha tudo limpo
Por que se importar com o estilo de código? Pensamos no longo prazo, e um estilo consistente facilita a manutenção. Estilo se refere a como você nomeia suas variáveis, mas também abrange como você estrutura o código, escreve comentários e muito mais. Sempre que possível, usamos ferramentas como o eslint para automatizar verificações de estilo.
Além do eslint, siga estes guias:
- Guia de estilo do JavaScript do Google.
- Guia da mensagem de confirmação
- Diretrizes sobre o uso das APIs Blockly
- Guia de estilo do codelab
Teste a mudança
Antes de apresentar um PR, você sempre deve testar se as alterações estão funcionando, para que não precise voltar e corrigir algo mais tarde. Confira algumas ideias para testar as diferentes categorias de projetos:
- Para plug-ins: escreva testes mocha automatizados que cubram suas mudanças.
- Exemplos: teste manualmente toda a funcionalidade demonstrada.
- Para codelabs: siga o tutorial inteiro em um ambiente limpo e teste qualquer exemplo de código fornecido.
Comunicação
Esta é a última e, sem dúvida, a parte mais importante da criação de um PR: escrever o resumo.
Escrever um bom resumo de RP ajuda outros desenvolvedores a revisar suas alterações, aumentando a probabilidade de que elas sejam aceitas mais rapidamente.
Seu resumo deve incluir itens como:
- A que problema seu PR está relacionado.
- Que mudança seu RP adiciona.
- Como você testou a mudança.
- Tudo que você quer que os revisores examinem.
- Outras informações que você achar que os revisores precisam.
Se você seguir o modelo de relações públicas ao criar sua solicitação, tudo estará pronto. Lembre-se de ser o mais conciso e completo possível.
Boa programação!