Template para criação de Issues
Uma boa tarefa está relacionada a algum requisito do sistema (ou correção) e contém detalhes que ajudem a traduzir um requisito (abstrato) para algo mais concreto. Em resumo, que facilite (e clarifique) o que deve ser implementado.
Sugestões para auxiliar a criação de tarefas
- Defina um milestone no projeto. Um milestone representa uma versão. Ele contém um conjunto de requisitos (funcionalidades/desejos) para aquela versão
- Utilize as labels do projeto para a criação de tarefas
- As labels do projeto são divididas em categorias (cores)
- type: Tipo - define qual o tipo da tarefa
- state: Estado - Progresso da tarefa
- priority: Prioridade - o quão importante/critica é essa tarefa
- effort: Dificuldade -o quão difícil é essa tarefa
- comp: Componente - Quais componentes serão modificados
- De um requisito do milestone tente extrair uma tarefa (compreenda o requisito)
- Em caso de dúvida sobre a compreenção de um requisito ou qual seria a melhor forma de implementar o requisito pode-se começar com uma tarefa de discução (type: discussion). Tarefas desse tipo são usadas para registrar que uma conversa/discução com a equipe ou professores para entender melhor um requisito. Tarefas desse tipo não geram commits, mas no fechamento da tarefa pode ser colocado os resultados da discução (edição da tarefa ou como comentário)
- Associe a tarefa ao milestone
- Com uma compreenção melhor do requisito pode-se criar uma tarefa "normal", escolher a tag de tipo (feature, bug, refactor) que melhor representa a mudança que será feita. Normalmente uma tarefa só tem um tipo
- Escolhido o tipo, defini-se quais os componentes que serão modificados. A quantidade de componentes é utilizada como estimativa de dificuldade da tarefa (effort)
- Se a tarefa está envolvendo muitos componentes, verifique a possibilidade de dividir em várias tarefas
- Após esses passos escolher a prioridade da tarefa
- Com essas informações pode-se estimar a dificuldade das tarefas. Dois critérios para a dificuldade
- Quantidade de componentes alterados - Dá pra contar durante a criação da tarefa
- "Dificuldade" em cada componente - Precisa de experiência no projeto, pode perguntar ao dev. Quantidade de arquivos que serão modificados e quais arquivos (alguns arquivos são mais complexos que outros) são indicativos
- Definir estado
- Ready - Pronta para começar (ainda não iniciada)
- Development - Em desenvolvimento
- Blocked - Não pode ser iniciada, normalmente depende que outra tarefa termine antes
- Escrever o texto que descreve a tarefa. Descrição do texto é formada por
- Requisito a ser cumprido ou causa do bug (situação)
- Alterações (estimadas) nos componentes
- Para melhor saber as alteraçoes precisa saber a arquitetura do sistema
- Pode perguntar aos devs o que eles acham
- Alteraçoes normalmente sao - adicao de classe/interface, modificaçao de classe/interface
- E melhor compreender a arquitetura da soluçao do que como exatamente estao implementados os componentes