Escreva uma boa solicitação de envio

As solicitações de envio são como o sangue de um repositório. Elas mantêm tudo saudável e em movimento. Esta página detalha como criar uma PR completa e fácil de analisar, o que aumenta a probabilidade de que ela seja mesclada.

Confira as etapas que você pode seguir para criar a melhor RP possível.

  1. Comunicação
  2. Configurar
  3. Mantenha o tamanho pequeno
  4. Mantenha a simplicidade
  5. Testar a mudança
  6. Comunicar (pt2)

Entrar em contato com as pessoas

Antes de começar a escrever código, é útil se comunicar com a equipe principal para que ela saiba no que você está interessado.

Se houver um problema que você tenha interesse, coloque um comentário sobre ele dizendo que você vai começar a trabalhar nele. Isso garante que não tenhamos várias pessoas trabalhando na mesma coisa. Um membro da equipe vai responder para confirmar que ele é seu.

Se você tiver uma ideia que não se enquadra em um problema, escreva uma antes de começar a trabalhar. Isso dá à equipe a chance de discutir a melhor forma de criar a mudança antes de começar a criar, o que economiza trabalho a longo prazo.

Começar a configuração

Se esta é a primeira vez que você contribui para o Blockly ou o blockly-samples, comece na página Configuração de desenvolvimento.

Mantenha o tamanho pequeno

Sempre tente manter as mudanças pequenas e focadas. Preferimos analisar várias PRs menores do que uma gigante. Algumas boas regras gerais são:

  • Corrigir um problema. Não tente resolver vários problemas de uma só vez.
  • Limite o escopo. Normalmente, uma PR leva menos de 8 horas (dependendo da sua familiaridade com a base de código).
  • Use as confirmações. Se a PR parecer um pouco grande, divida as mudanças em grupos lógicos usando confirmações do Git.

Estilo clean

Por que se preocupar com o estilo do código? Estamos aqui para o longo prazo, e um estilo consistente facilita a manutenção. O estilo se refere a como você nomeia suas variáveis, mas também abrange como você estrutura seu código, escreve comentários e muito mais. Sempre que possível, usamos ferramentas como o eslint para automatizar as verificações de estilo.

Além do eslint, siga estes guias:

Testar a mudança

Antes de enviar uma PR, sempre teste se as mudanças estão funcionando para que você não precise voltar e corrigir as coisas mais tarde. Confira algumas ideias para testar as diferentes categorias de projetos:

  • Para plug-ins, crie testes automatizados do Mocha que cubram suas mudanças.
  • Para exemplos: teste manualmente todas as funcionalidades demonstradas.
  • Para codelabs: execute todo o tutorial em um ambiente limpo e teste todos os exemplos de código fornecidos.

Entrar em contato com as pessoas

Esta é a última e, sem dúvida, a parte mais importante da criação de uma RP: escrever o resumo.

Escrever um bom resumo de RP ajuda outros desenvolvedores a analisar suas mudanças, aumentando a probabilidade de que elas sejam aceitas mais rapidamente.

Seu resumo deve incluir informações como:

  • O problema relacionado à sua solicitação de alteração.
  • Que mudança sua solicitação de alteração adiciona.
  • Como você testou a mudança.
  • Qualquer coisa que você queira que os revisores analisem.
  • Outras informações que você acha que os revisores precisam.

Se você seguir o modelo de PR ao criar sua solicitação, estará tudo bem. Basta lembrar de ser o mais conciso e completo possível.

Bom trabalho!