maurochiozzi
commented
4 years ago Etiquetas devem ter regras simples a fim de encorajar os contribuidores do projeto a utilizarem-as. Ao criar regras complexas, por mais que haja uma automatização, pode fazer com que o usuários recuem no momento de criar uma nova issue ou faça com que eles utilizem as etiquetas de forma errônea. Para isso, na criação das etiquetas deve ser levado em consideração quem será o público que irá abrir os chamados para tópicos importantes/problemas (issues).
Vamos supor que seu público seja alunos da Engenharia Ambiental. Sabemos que a realidade está ficando mais favorável, mas ainda temos pouca adesão desta área em relação a desenvolvimento de software como um todo, ainda mais quando falamos de ferramentes como o GIT. Estes alunos podem encarar as etiquetas como algo complexo, por mais que haja uma ferramenta terceira que auxilia eles nesse processo. Mas veja só, uma pessoa que não detêm muita afinidade com essas ferramentas, estaria ela disposta a clonar um repositório, e (tentar) usar uma ferramenta, em uma linguagem X, correndo o risco de nunca ter tido contato com a mesma?
Por outro lado, temos a questão de gestão dessas issues. Enquanto estamos tentando simplificar uma etapa do processo para o usuário, a fim de encorajar a utilização delas, não podemos simplificar ao extremo e acabar prejudicando gestão. Nessa parte, deve ser levado em consideração quais são os principais fatores que o gestor irá acompanhar, e analisar quais podem ser deixadas de lado, tornando uma gestão a vista mais limpa e direta.
Intrometendo na gestão adotada pela Imobanco, continuo a seguinte explicação:
Cores são importantes para uma análise rápida. E como podemos perceber na imagem 'Com pouco zoom', é que existe um boa variedade de cores. Contudo, analisado num escopo macro, essa cor apenas realça um atributo de cada categoria. Afirmo isso pois as cores são ferramentas utilizadas para facilitar a interpretação da informação na gestão a vista. E se você tem, por exemplo, uma cor vermelha, que é utilizada tanto para atributos das categorias 'Prioridade', 'Status', 'Tipo', e o que parece ser diversos, podemos notar que, em uma passagem rápida na gestão visual, principalmente na figura 'Com pouco zoom' - pois é um ótimo exemplo -, não é possível distinguir de forma assertiva quais itens são críticos e a quais categorias eles pertencem, sendo esse último ponto não muito relevante quando bem estruturado os esquemas de cores.
Um exemplo consistente de utilização de cores está relatado no exemplo do repositório do covid19-br. Perceba que não importa o quão perto ou não (zoom in/out) for observado a lista de issues, podemos sempre concluir que a cor amarela esta associada a data-scraping. Outro bom exemplo da utilização das cores, para agrupar, está nas etiquetas do NixOS.
Por último, uma etiqueta não precisa obrigatoriamente ter uma cor única. Os atributos podem ter uma cor neutra (comum) caso seja julgado que essa etiqueta não agrega informação quando sendo destacada. Um exemplo para reflexão: será que no Imobanco, é realmente necessário destacar de forma gráfica as etiquetas de 'Tipo: Documentação', 'Tipo: Testando', 'Tipo: Funcionalidade'? Não poderia ser utilizado uma única cor para esses casos, como por exemplo, cinza?
Essa simplificação de cores ajuda o gestor, e também tem um grande impacto para o usuário na hora de não se perder na hora de escolher uma cor no leque de cores de tinta para a parede da sala, que ele também vai ter que escolher para discutir sobre um determinado assunto.
P.S.: Lembrando que gestão de projeto varia de acordo com projeto/equipe, e o que pode parecer complexo/redundante para quem está de fora, pode funcionar muito bem para quem está atuando diretamente no projeto e já estar bastante consolidado. Assim afirmo que o exemplo que descrevi sobre o Imobanco, foi interpretação e percepção pessoal das imagens aqui divulgadas.
Resumo
Para iniciar o projeto é necessário que se tenha boas etiquetas/labels para issues (note que a tradução para issue não é muito boa), pois assim será possível que se gerencie o projeto.
Exemplo de repositório que utiliza labels e no qual pretendo me inspirar
O repositório de exemplo que vou usar para ilustrar é o zoop-wrapper. Este é um repositório público desenvolvido e mantido pela equipe de TI do Imobanco. Esta equipe criou a organização no github com o mesmo nome: Imobanco. Para ver as issues do zoop-wrapper basta clicar no link. Note: issues são modificados, resolvidos, e novos são criados, ou seja, é provável que quando você consulte o link das issues elas estejam diferentes das exibidas nas imagens.
Com pouco zoom:
Com algum zoom:
Com bastante zoom:
Não poderia deixar de citar um outro repositório, o do covid19-br, repositório este que organiza os dados dos boletins informativos e casos do coronavírus por município por dia do Brasil do brasil.io.
Coloquei essa sequência de zooms para caso alguém acesse via smartphone e tenha dificuldade em visualizar as imagens.
Note: é possível clicar nas imagens para vê-las melhor, se assim for desejado.
Requisitos para adicionar os labels neste repositório
Apesar de ser perfeitamente possível que se adicione/modifique/delete os labels das issues manualmente, para o caso de um conjunto (grande) e predefinido, como o que pretendo utilizar, a "preguiça esperta" dos programadores fez com que estes automatizassem essa tarefa.
Existe esse script Python que automatiza essa tarefa e está nesse repositório. Entretanto, esse script não está tão imediato de ser utilizado. Assim sendo, pretendo fazer algumas modificações que melhorem a utilização deste.
As principais modificações são sobre sanar dúvidas que tenham surgido ao longo do processo e a realização do empacotamento deste script usando NixOS, Docker e etc.
Como diretriz geral para essas modificações, vou documentar tudo que julgar relevante para este processo, para após o término da tarefa fazer um Pull Request com as contribuições pertinentes para o github-labels.
Tarefas