vStack — Criando Issues
Como abrir uma issue que não precisa ser reescrita depois
Toda tarefa começa como issue no vStack. Uma issue bem escrita já é o plano — não precisa de documento separado.
O que uma issue precisa ter
Título que diz o problema, não a solução
"Filtro de qualificação não vive na URL" é útil. "Ajustar DealsPage" não é.
Descrição com o que o usuário sente
O que acontece hoje, o que deveria acontecer, e — quando for bug — como reproduzir. Escreva do ponto de vista de quem usa, não de quem implementa.
Critérios de aceite
Como se prova que terminou. Se estiverem vagos, quem for implementar vai ter que perguntar — e perguntar depois custa uma rodada.
Etiqueta, projeto, prioridade e responsável
Os quatro. Cartão sem eles não aparece direito no board.
Uma issue, uma branch, um PR
Se a tarefa crescer durante a execução, quebre em outra issue — não empilhe no mesmo PR.
Exceção conhecida: quando várias issues pequenas do mesmo assunto são trabalhadas juntas, elas vão num PR só para o lote inteiro, com todas referenciadas no corpo.
Quando devolver em vez de entregar errado
Devolva a issue para Todo, com comentário dizendo o que trava, quando:
- os critérios de aceite estiverem vagos ou ambíguos
- a tarefa exigir migration, dependência nova, ou chave/credencial
- o escopo crescer durante a execução
- o que trava for decisão de produto
Perguntar é barato; desfazer código errado é caro.
O que não vira issue
Brainstorm, ideia solta e "seria legal se" não viram issue — viram plano em .planning/a-fazer/. Issue é trabalho com escopo fechado e critério de pronto.