Las notificaciones de un bug tracker fallan en dos direcciones. Si envías pocas, el jueves descubres que el bug que estabas corrigiendo se reasignó el lunes. Con demasiadas, al tercer día todo el mundo tiene un filtro de correo y una carpeta que nunca abre. El resultado es el mismo en los dos casos. La gente deja de confiar en el canal, y la única notificación que importaba se queda sin leer.
Acabo de lanzar las notificaciones de tareas en BugDump. Enviarlas fue la parte fácil. La mayor parte del trabajo se fue en decidir quién debe recibir una y cuándo no decir nada. Estas son las reglas con las que me quedé, y por qué.
Empieza por una pregunta
Para cada notificación, pregúntate: ¿esta persona haría algo distinto por recibirla?
Un desarrollador cuya tarea QA acaba de marcar como resuelta: sí, deja de trabajar en ella. La persona que reportó el bug: sí, puede ir a comprobar la corrección. Un compañero que echó un vistazo a la tarea hace un mes: no. Enviársela igualmente cuesta más que un correo desperdiciado. Le enseña que la campana es casi todo ruido, y la siguiente la lee con un poco menos de atención.
Todo lo que sigue sale de esa pregunta.
Saca los destinatarios de la propia tarea
La mayoría de los trackers responden a «quién se entera de esto» con observadores (watchers). Haces clic en «Observar» y lo recibes todo. Suena flexible. En la práctica, las listas de observadores se quedan desfasadas. La gente olvida seguir la tarea que le importa y se queda en las que dejaron de importarle hace meses. Una lista que alguien tiene que mantener a mano suele estar desactualizada.
Así que en BugDump no hay ninguna lista. Cuando una tarea cambia, BugDump deduce quién participa a partir de la tarea tal como está en ese momento:
quien la creó,
la persona asignada,
cualquiera que figure en un campo de miembro, como Revisor o Responsable de QA,
todos los que han comentado en ella.
Comentar es la señal más fuerte de las cuatro. Quien se tomó el tiempo de escribir en una tarea te ha dicho, sin decirlo, que quiere saber cómo termina.
Un campo de miembro es la versión deliberada. Si quieres que alguien de diseño siga un bug, ponlo en el campo Revisor. Se enterará del próximo comentario y del próximo cambio de estado, y cuando lo quites, dejará de recibirlos. Nadie tiene que acordarse de darse de baja, y quien deja el proyecto sale de todas sus tareas a la vez.
La contrapartida es real: no puedes seguir una tarea en la que no participas. Decidí que podía vivir con eso hasta que alguien lo pida de verdad.
Nunca le cuentes a nadie lo que acaba de hacer
Suena demasiado obvio para escribirlo. Deja de serlo cuando entran en juego los agentes de IA.
Cuando tu agente mueve una tarea a «Hecho» con tu token MCP, esa acción es tuya. Notificártela es ruido, porque fuiste tú quien la pidió. Tus compañeros sí deberían enterarse, y deberían poder distinguir que no fuiste tú quien hizo clic, así que su notificación dice Alex Rivera vía MCP.
Un cambio, una notificación
Lo difícil fueron los casos en los que una sola decisión aparece como varios cambios.
Un comentario que menciona a alguien. La persona @mencionada ya recibe «Te mencionaron». Enviarle también «Nuevo comentario» por el mismo comentario es un duplicado, así que solo recibe la mención.
Una ráfaga de triaje. El triaje casi nunca es una sola edición. Pones la prioridad, añades dos etiquetas y eliges una fecha límite, todo en menos de un minuto, y el editor de etiquetas guarda con cada clic. Con tres personas en la tarea, son doce notificaciones por lo que parecía una sola decisión.
Así que los cambios de propiedades de una persona en una tarea cuentan una sola vez cada cinco minutos. Cada destinatario recibe un único «Alex Rivera cambió Prioridad en AS-3» por toda la ráfaga. Un cambio de otra persona mientras tanto se sigue notificando por separado.
Por eso también la notificación nombra la propiedad y no el valor. «Cambió Prioridad a Alto» deja de ser verdad en cuanto el siguiente clic la pone en Crítico, y un correo no se puede corregir una vez enviado. «Cambió Prioridad» sigue siendo verdad, y el valor actual está a un clic.
Una acción masiva. Mover 30 tareas a «Hecho» también es una sola decisión. Cada persona recibe una notificación con el número de tareas, y su botón abre el tablero en lugar de una tarea concreta.
El número cubre toda la acción, no solo las tareas en las que participa esa persona. Contar por persona habría obligado a esperar a que se procesaran todas las tareas del lote, y no me pareció que esa precisión compensara el retraso.
Lo que dejé fuera
Un resumen periódico (digest). Juntar los correos en un resumen por hora o por día parece una cortesía. Lo que hace en realidad es retener el único mensaje urgente para que llegue junto a cinco que no lo eran. BugDump envía un correo por cambio, con la ventana de cinco minutos en las ediciones de propiedades como única excepción. Si a alguien le parecen demasiados correos, puede desactivar el correo y tenerlo todo en la campana.
Una matriz de ajustes. Una cuadrícula de tipos de evento contra canales parece completa. La mayoría de la gente nunca la abre, y quienes la abren suelen desactivar casi todo. Acertar con los destinatarios hace más de lo que puede hacer una página de ajustes.
Cambios de los que nadie necesita enterarse. Editar un título, cambiar una columna entre abierta y cerrada en los ajustes del tablero, eliminar una tarea. Ninguno pasa la prueba de «¿haría algo distinto?», así que ninguno notifica.
Cómo funciona en BugDump
Hay cuatro notificaciones de tareas: «Asignada a ti», «Nuevo comentario», «Estado cambiado» y «Propiedad cambiada». Aparecen en la campana y se envían por correo en el idioma de cada persona, en todos los planes, Gratis incluido.
Una notificación de comentario cita el principio del comentario, así que a menudo basta con la notificación para saber si necesitas abrir la tarea.
Las reglas completas, incluido todo lo que no envía notificación, están en el centro de ayuda: Notificaciones de tareas: quién se entera de un cambio.
Te puede interesar
Campos personalizados en un bug tracker: qué añadir y qué evitar — qué campos se ganan su sitio en una tarea y cuáles acaban vacíos.
Métricas de bugs que de verdad importan — qué números dicen algo sobre tus bugs y cuáles solo llenan un dashboard.
Cómo hacer el triaje de bugs más rápido: un flujo de trabajo con el teclado — cómo repasar una columna entera de reportes sin soltar el teclado.