Entendendo a parte técnica da sua startup— Parte 4 de 4
Para founder não técnico
Neste artigo iremos:
- Aprender como utilizar o gerenciamento de issues do GitHub;
- Configurar e usar Projects com Kanban diretamente no repositório;
- Usar labels nas issues.
O ferramental do GitHub é bem extenso, algumas ferramentas são de utilização esporádica, porem as issues é para utilização constante. Embora a tradução de issues possa ser problemas em português, não é somente para isso que ela é utilizada.
Issues
A aba Issues é encontrada ao lado da aba Code, na página principal do projeto, vamos criar uma issue para começar a desbravar essa ferramenta que na minha opinião é uma das principais do GitHub.
Acima vemos a tela de inclusão de issues para o projeto hello-world que criamos na parte 1 desta série de artigos, algumas considerações são importantes para escrever sua issue no sistema.
- O título é importante, seja breve porem tente passar todas as principais características da issue;
- Na descrição seja o mais claro possível, se for nova funcionalidade deixe claro qual o resultado esperado, se for um bug descreva o que aconteceu em detalhes e como reproduzir o erro, qual o dispositivo, sistema operacional, browser, enfim, o máximo de informação possível.
- Caso saiba para quem direcionar a issue, utilize o Assignees para o colaborador saber que ele quem deve tomar a frente e cuidar dela, caso não saiba, deixe em branco.
- Label é muito importante, falaremos mais a respeito logo abaixo, o que deve já ficar em sua mente é que elas são utilizadas para facilitar a filtragem das issues.
- Projects é uma maneira de separar seu projeto principal em partes, vamos supor que você tem um squad trabalhando em uma funcionalidade x e outro em uma funcionalidade y, você pode separar e direcionar issues para cada projeto individualmente, Projects também te dá a facilidade de ter tudo separado em Kanban direto na página do repositório.
- Milestone são normalmente os momentos de entrega do seu projeto, por exemplo podemos definir um milestone como versão MVP pronta para produção.
Alem de organizar suas histórias dentro de uma plataforma única, issues também servem como histórico de discussões, por meio do sistema de comentário individual de cada uma e ainda quando feito o commit, um link pode ser feito para a issue resolvida pelo mesmo, mantendo desta forma um log completo, desde a criação da issue até o pedaço de código que a solucionou passando pelas discussões de como a solução deveria ser implementada.
Project
Para abrir um novo project basta clicar na aba Projects, no botão New Project e preencher o formulário, você também pode escolher entre vários templates, desde o Kanban básico até versões automatizadas.
Na imagem acima vemos o Project — Login utilizando terceiros — já com dois cards, um em Roadmap e outro na aba In progress, perceba que este último tem o ícone da conta johncalistro como responsável (assignees). Você pode direcionar a issue para mais de um responsável quando necessário.
Você pode ter a quantia de projetos que achar conveniente para seu repositório e os cards podem constar em mais de um projeto.
Labels
Considero a parte mais poderosa disso tudo que estamos falando neste artigo, o GitHub já cria o repositório com algumas labels padrão: bug, duplicate, enhancement, good first issue, help wanted e invalid.
Você pode criar, apagar e editar as labels conforme sua conveniência, lembre-se que estas que o GitHub cria como padrão são conhecidas por todos que usam o sistema de issues, portanto utiliza-las fará com que treinamento não seja necessário para explicá-las.
E por que eu digo que elas são poderosas?
Não importa o que está escrito na imagem acima, a da esquerda já passa muitas informações só por causa das tags, se eu soubesse as cores, já poderia identificar muitos padrões de primeira.
Outra funcionalidade poderosa das labels é auxiliar no filtro de issues, basta clicar em uma delas para somente issues que contem a label sejam listadas, um bom exemplo de utilização dessa feature é quando queremos saber somente quais as issues se referem a bug, que devem ser priorizados sempre, qual listagem acima você acha que será mais fácil descobrir onde estão as relacionadas com bug?
Espero que este artigo tenha sido útil para você, deixe um comentário se tiver alguma dúvida sobre o que foi escrito acima, isso ajudará a melhorar ainda mais o artigo.
Outros artigos desta série:
