Como usar os modelos de relações públicas do GitHub

Se você faz algum trabalho – independentemente de ser de código aberto ou de código fechado – (embora eu saiba que a maioria dos que usam este site estão envolvidos em código aberto), você provavelmente usa algum controle de origem, e provavelmente é o GitHub.

Para muitos de vocês, você segue um projeto, contribui para um projeto ou lida com pull requests para um projeto. E os projetos em que você trabalha em equipe?

Talvez seu fluxo de trabalho seja algo assim:

• você cria uma ramificação para trabalhar em um recurso,
• você empurra a ramificação para detalhar o trabalho que você fez para um colega revisar,
• a revisão é mesclada,
• você continua.

Mas o que você coloca no modelo para o pull request? É sempre o mesmo ou é diferente? E se o conteúdo do PR estiver relacionado a algo no Trello, Asana, Basecamp ou algum outro sistema de gerenciamento de projetos?

É aí que os modelos de relações públicas do GitHub entram em ação.

Modelos de relações públicas do GitHub

Você pode ler tudo sobre eles na página, mas aqui está a essência (sem trocadilhos):

É difícil resolver um problema quando faltam detalhes importantes. Agora, os mantenedores do projeto podem adicionar modelos para problemas e solicitações pull aos projetos, ajudando os contribuidores a compartilhar os detalhes corretos no início de um tópico

E a ideia é simples: criamos modelos para problemas e pull requests para outros que fornecem um nível de informação que eles devem preencher antes de enviar um problema ou um pull request.

Isso nos ajuda, pois os mantenedores sabem qualquer informação que precisamos antes de analisá-la. Além disso, pode nos permitir vincular a um problema anterior, ticket anterior, anterior a qualquer coisa relacionada ao projeto.

Por exemplo, digamos que você esteja trabalhando em um projeto e queira incluir as seguintes informações:

• uma breve descrição do que o PR faz para que o mantenedor não precise adivinhar,
• o status do PR sobre se ele deve estar pronto para ser mesclado ou se ainda está em desenvolvimento, mas pronto para alguma revisão,
• um link para o ticket em seu gerente de projeto para o qual o PR é relevante.

Não estou dizendo que esta é a informação necessária, mas é algo que usamos e achei útil (e é bom ver mais melhorias sendo feitas ao longo do tempo ).

Mas como usamos isso?

O site é bem claro, mas é bem simples. Você precisa dos seguintes arquivos no diretório do seu projeto ou no arquivo. diretório do github :

• ISSUE_TEMPLATE
• PULL_REQUEST_TEMPLATE

Cada um deles deve ser um arquivo markdown que mostra exatamente o que você está procurando para que seus contribuidores incluam sempre que eles estiverem, você sabe, contribuindo para o seu projeto de alguma forma.

E então, sempre que um usuário procura relatar um problema ou criar uma solicitação pull, ele solicita as informações do modelo.

Legal, não é?

Não é muito, mas…

Você pode achar que não é muito, mas é muito fácil ajudar a melhorar a qualidade das informações que chegam a um projeto, fazer com que seus colaboradores pensem sobre o que estão colocando no projeto e então respondam de acordo.

Além disso, ajuda você e o restante de sua equipe a entender o que está prestes a ser revisado e a se preparar para quaisquer mudanças que possam surgir ao trabalhar nesses projetos.