Lance algo para alguns milhares de usuários e a primeira coisa que você aprende é que os relatórios de bug não chegam um por bug.
Um único checkout quebrado gera quarenta relatórios numa tarde. Se você tratar isso de forma ingênua, são quarenta itens para ler, quarenta para categorizar e trinta e nove para fechar como duplicados. O dia mais movimentado do seu bug tracker é o que produz menos informação.
Relatórios e tarefas são coisas diferentes
O BugDump os mantém separados, e essa é a decisão estrutural sobre a qual todo o resto se apoia.
Um relatório é um envio de um usuário em um momento — a descrição dele mais tudo o que o SDK capturou. Relatórios são evidências imutáveis. Nunca são editados, nunca são mesclados, nunca são deduplicados.
Uma tarefa é o que você corrige. Ela tem um ID público, uma coluna no quadro, comentários e um histórico de atividade.
Muitos relatórios se ligam a uma tarefa. Quarenta relatórios sobre o checkout viram uma tarefa com quarenta evidências.
A distinção não é burocracia. Ela reflete algo verdadeiro: a evidência e o trabalho são objetos diferentes, com ciclos de vida diferentes. A evidência se acumula e nunca muda. O trabalho passa por estados e, em algum momento, termina. Sistemas que misturam os dois obrigam você a escolher — ou você perde evidências ao mesclar duplicados, ou se afoga em itens, porque cada evidência também é uma tarefa.
Duplicados são um ativo
Quando os relatórios se ligam a tarefas, os duplicados deixam de ser ruído. Viram o seu melhor sinal para depuração.
Quarenta relatórios numa tarefa dão algo que nenhum relatório isolado dá: a interseção.
Se todos os quarenta são do Safari, é um bug do Safari — e você soube disso antes de abrir um depurador. Se eles cobrem todos os navegadores, mas têm em comum uma viewport abaixo de 768px, é um problema de responsividade. Se todos chegam numa janela de quinze minutos e depois param, foi um deploy, e você deveria olhar o que foi lançado em vez do seu código.
Essa análise leva segundos quando os relatórios estão agrupados e é quase impossível quando são quarenta itens separados numa lista. O formato mais comum de um incidente real — muita gente esbarrando na mesma coisa — é justamente o que uma caixa de entrada sem agrupamento trata pior.
É aqui também que o servidor MCP mostra o seu valor. «Leia os relatórios da #17 e me diga quais navegadores são afetados» é uma pergunta que um agente responde em segundos lendo os quarenta. Comparar relatórios entre si é tedioso o bastante para que as pessoas pulem essa etapa, e é por isso que vale automatizar.
O quadro
As tarefas ficam num quadro kanban com colunas que você define. Cada coluna corresponde a um de dois estados: aberto ou fechado.
O que importa é essa correspondência, não o nome. Você pode usar:
Triagem → Confirmado → Em andamento → Concluído → Não será corrigido
As três primeiras são open e as duas últimas, closed. Ou você pode usar algo completamente diferente — o modelo de dois estados faz o sistema entender o que está pendente, seja qual for o nome das suas colunas.
Dois estados, não cinco. Toda taxonomia do tipo «Adiado / Bloqueado / Precisa de informação / Aguardando cliente» que já vi termina do mesmo jeito: uma coluna que se enche de tarefas que ninguém volta a olhar. Se uma tarefa não está concluída, está aberta, e o trabalho aberto deve ficar visível.
Também é proposital que Não será corrigido corresponda a closed. Decidir não corrigir algo é uma resolução de verdade. A tarefa deve sair da sua fila de abertas.
Um ciclo de triagem que funciona
Leia os relatórios novos e agrupe. A maioria é duplicada. Ligue-os às tarefas existentes. Esses são os dez minutos que mais rendem no processo — quarenta itens viram seis.
Crie tarefas para o que é realmente novo. Uma por bug distinto.
Use a interseção. Em toda tarefa com vários relatórios, veja o que eles têm em comum antes de olhar o código.
Mova, não anote. A posição no quadro é o status. Uma tarefa na coluna Em andamento com um comentário dizendo «na verdade, está bloqueada» está na coluna errada.
Feche as tarefas. Inclusive as que você não vai corrigir.
Fechando o ciclo
Cada projeto pode publicar um portal público em your-project.bugdump.com, onde quem reportou acompanha as tarefas que abriu.
Esta é a parte que a maioria das ferramentas pula, e é a que determina se você continua recebendo relatórios.
Um usuário que reporta um bug e não recebe nenhum retorno conclui que reportar não adianta. Ele está tirando uma conclusão racional das evidências disponíveis. Da próxima vez que algo quebrar, ele contorna o problema em silêncio — e você perde o sinal.
Um usuário que vê a tarefa dele ir de Confirmado para Concluído aprendeu a lição oposta. Ele reporta o próximo bug, e o seguinte também.
Você também pode deixar que quem reporta ligue o relatório a uma tarefa por conta própria. Com allowTaskAttach ativado, quem conhece o ID público de uma tarefa envia o relatório diretamente para ela. Para grupos internos de QA e de beta que já acompanham os IDs das suas tarefas, isso elimina a sua etapa de triagem — quem reporta agrupa os próprios duplicados.
Em poucas palavras
Relatórios são evidências. Tarefas são trabalho. Mantenha os dois separados, deixe os duplicados se acumularem como evidência em vez de brigar com eles, mantenha o quadro com dois estados reais e mostre a quem reportou o que aconteceu.
Quarenta relatórios viram seis bugs, e os seis chegam com evidências melhores do que qualquer relatório isolado poderia trazer.
Leia também
Como fazer a triagem de bugs mais rápido: um fluxo guiado pelo teclado — um fluxo de triagem que tira a navegação do caminho em vez de pedir que você decida mais rápido.
Como coletar relatórios de bug de beta testers sem perder metade deles — menos atrito para reportar, contexto capturado automaticamente e um retorno para quem testou.
Níveis de prioridade de bugs: por que quatro opções fixas nunca servem — para que serve uma escala de prioridade, quantos níveis ela precisa ter e por que os nomes têm que ser os seus.