As notificações de um bug tracker erram em duas direções. Mande poucas, e na quinta-feira você descobre que o bug que estava corrigindo foi reatribuído na segunda. Mande demais, e no terceiro dia todo mundo tem um filtro de e-mail e uma pasta que nunca abre. O resultado é o mesmo nos dois casos. As pessoas param de confiar no canal, e a única notificação que importava fica sem ser lida.
Acabei de lançar as notificações de tarefas no BugDump. Enviá-las foi a parte fácil. A maior parte do trabalho foi decidir quem deve receber cada uma e quando não dizer nada. Estas são as regras a que cheguei, e por quê.
Comece com uma pergunta
Para cada notificação, pergunte: essa pessoa faria algo diferente por causa dela?
Um desenvolvedor cuja tarefa o QA acabou de marcar como resolvida: sim, ele para de trabalhar nela. Quem registrou o bug: sim, pode ir conferir a correção. Um colega que deu uma olhada na tarefa há um mês: não. Mandar para ele mesmo assim custa mais que um e-mail desperdiçado. Ensina que o sino é quase só ruído, e ele lê a próxima com um pouco menos de atenção.
Tudo o que vem abaixo sai dessa pergunta.
Defina os destinatários a partir da tarefa
A maioria dos trackers responde a «quem fica sabendo disso» com observadores. Você clica em Observar e recebe tudo. Parece flexível. Na prática, as listas de observadores se desatualizam. As pessoas esquecem de observar a tarefa que importa para elas e continuam nas que deixaram de importar meses atrás. Uma lista que alguém precisa manter manualmente geralmente está desatualizada.
Por isso o BugDump não mantém uma. Quando uma tarefa muda, o BugDump descobre quem está envolvido a partir da tarefa como ela está naquele momento:
quem a criou,
o responsável,
qualquer pessoa indicada num campo de membro, como Revisor ou Responsável por QA,
todo mundo que comentou nela.
Comentar é o sinal mais forte dos quatro. Quem tirou um tempo para escrever numa tarefa já disse, sem dizer, que quer saber como ela termina.
O campo de membro é a versão deliberada. Se você quer que o designer acompanhe um bug, coloque-o no campo Revisor. Ele fica sabendo do próximo comentário e da próxima mudança de status, e, quando você o tira, as notificações param. Ninguém precisa lembrar de cancelar a inscrição, e quem sai do projeto deixa de acompanhar todas as tarefas dele de uma vez.
A contrapartida é real: você não consegue acompanhar uma tarefa da qual não faz parte. Decidi que dá para conviver com isso até alguém pedir de fato.
Nunca avise alguém do que essa pessoa acabou de fazer
Parece óbvio demais para escrever. Fica menos óbvio quando há agentes de IA no meio.
Quando o seu agente move uma tarefa para Concluído com o seu token MCP, a ação é sua. Avisar você disso é ruído, já que foi você quem pediu. Seus colegas ainda devem ficar sabendo, e devem conseguir perceber que não foi você clicando, então a notificação deles diz Alex Rivera via MCP.
Uma mudança, uma notificação
A parte difícil foram os casos em que uma única decisão aparece como várias mudanças.
Um comentário que menciona alguém. A pessoa @mencionada já recebe «Você recebeu uma menção». Mandar também «Novo comentário» pelo mesmo comentário é duplicar, então ela recebe só a menção.
Uma rajada de triagem. A triagem raramente é uma edição só. Você define a prioridade, adiciona duas etiquetas e escolhe uma data de entrega, tudo em menos de um minuto, e o editor de etiquetas salva a cada clique. Com três pessoas na tarefa, são doze notificações para o que pareceu uma decisão só.
Por isso as mudanças de propriedades que uma pessoa faz numa tarefa contam uma vez a cada cinco minutos. Cada destinatário recebe um único «Alex Rivera alterou Prioridade em AS-3» para a rajada inteira. Uma mudança feita por outra pessoa nesse meio-tempo continua gerando a própria notificação.
É também por isso que a notificação diz qual propriedade mudou, e não o valor. «Alterou Prioridade para Alto» fica errado assim que o próximo clique muda para Crítico, e um e-mail não pode ser corrigido depois de enviado. «Alterou Prioridade» continua verdadeiro, e o valor atual está a um clique de distância.
Uma ação em massa. Mover 30 tarefas para Concluído também é uma decisão só. Cada pessoa recebe uma notificação com a contagem, e o botão dela abre o quadro, não uma tarefa específica.
A contagem cobre a ação inteira, não só as tarefas em que aquela pessoa está envolvida. Contar por pessoa obrigaria a esperar até que cada tarefa do lote fosse processada, e achei que essa precisão não valia o atraso.
O que deixei de fora
Um resumo periódico. Juntar os e-mails num resumo por hora ou por dia parece atencioso. O que isso faz, na prática, é segurar a única mensagem urgente para que ela chegue junto com cinco que não eram. O BugDump envia um e-mail por mudança, e a única exceção é a janela de cinco minutos para edições de propriedades. Se for e-mail demais para alguém, a pessoa pode desligar o e-mail e manter tudo no sino.
Uma matriz de configurações. Uma grade de tipos de evento contra canais parece completa. A maioria das pessoas nunca a abre, e quem abre costuma desligar quase tudo. Acertar os destinatários resolve mais do que uma página de configurações.
Mudanças que ninguém precisa saber. Editar um título, alternar uma coluna entre aberta e fechada nas configurações do quadro, excluir uma tarefa. Nenhuma delas passa no teste do «faria algo diferente», então nenhuma gera notificação.
Como funciona no BugDump
São quatro notificações de tarefa: Atribuída a você, Novo comentário, Status alterado e Propriedade alterada. Elas aparecem no sino e são enviadas por e-mail no idioma de cada pessoa, em todos os planos, inclusive o Grátis.
Uma notificação de comentário cita o início do comentário, então muitas vezes dá para saber pela notificação se você precisa abrir a tarefa.
As regras completas, incluindo tudo o que não gera notificação, estão na central de ajuda: Notificações de tarefas: quem fica sabendo de uma mudança.
Leia também
Campos personalizados no bug tracker: o que adicionar e o que evitar — o teste que separa um campo útil de um que vai estar vazio em seis semanas, e os quatro que se pagam.
Métricas de bugs que importam de verdade — quatro métricas que mostram se a equipe está dando conta dos bugs, e uma revisão semanal de cinco minutos baseada nelas.
Como fazer a triagem de bugs mais rápido: um fluxo guiado pelo teclado — uma rotina de triagem que corta a navegação em vez de pedir que você pense mais rápido.