Les notifications d'un bug tracker ratent de deux façons. Envoyez-en trop peu, et jeudi vous découvrez que le bug que vous corrigez a été réassigné lundi. Envoyez-en trop, et au troisième jour tout le monde a un filtre de messagerie et un dossier qu'il n'ouvre jamais. Le résultat est le même dans les deux cas. Les gens cessent de faire confiance au canal, et la seule notification qui comptait reste non lue.
Je viens d'ajouter les notifications de tâches à BugDump. Les envoyer, c'était la partie facile. L'essentiel du travail a consisté à décider qui doit en recevoir une, et quand ne rien dire. Voici les règles auxquelles je suis arrivé, et pourquoi.
Partir d'une seule question
Pour chaque notification, demandez-vous : est-ce que cette personne ferait quelque chose différemment grâce à elle ?
Un développeur dont la QA vient de marquer la tâche comme résolue : oui, il arrête de travailler dessus. La personne qui a signalé le bug : oui, elle peut aller vérifier le correctif. Un collègue qui a jeté un œil à la tâche il y a un mois : non. La lui envoyer quand même coûte plus qu'un e-mail perdu. Elle lui apprend que la cloche, c'est surtout du bruit, et il lira la suivante avec un peu moins d'attention.
Tout ce qui suit découle de cette question.
Déduire les destinataires de la tâche
La plupart des trackers répondent à « qui est prévenu » avec des observateurs. Vous cliquez sur « Suivre » et vous recevez tout. Ça a l'air souple. En pratique, les listes d'observateurs dérivent. Les gens oublient de suivre la tâche qui les concerne, et restent sur celles qui ont cessé de les intéresser depuis des mois. Une liste que quelqu'un doit tenir à jour à la main est en général périmée.
BugDump n'en tient donc pas. Quand une tâche change, il déduit qui est impliqué à partir de la tâche telle qu'elle est à ce moment-là :
la personne qui l'a créée,
la personne assignée,
toute personne indiquée dans un champ de type membre, comme Relecteur ou Responsable QA,
tous ceux qui l'ont commentée.
Le commentaire est le signal le plus fort des quatre. Quelqu'un qui a pris le temps d'écrire sur une tâche vous a dit, sans le formuler, qu'il veut savoir comment elle se termine.
Le champ de type membre en est la version délibérée. Si vous voulez que la designer suive un bug, mettez-la dans le champ Relecteur. Elle sera prévenue du prochain commentaire et du prochain changement de statut, et quand vous la retirez, ça s'arrête. Personne n'a à penser à se désabonner, et quelqu'un qui quitte le projet sort de toutes ses tâches d'un coup.
Le compromis est réel : vous ne pouvez pas suivre une tâche à laquelle vous ne participez pas. J'ai décidé que c'était acceptable tant que personne ne le demande vraiment.
Ne jamais prévenir quelqu'un de ce qu'il vient de faire
Ça paraît trop évident pour l'écrire. Ça l'est moins dès que des agents IA entrent en jeu.
Quand votre agent déplace une tâche dans Terminé avec votre jeton MCP, c'est votre action. Vous en notifier, c'est du bruit, puisque c'est vous qui l'avez demandée. Vos collègues doivent quand même l'apprendre, et pouvoir voir que ce n'est pas vous qui avez cliqué : leur notification indique donc Alex Rivera via MCP.
Un changement, une notification
Le plus difficile, ce sont les cas où une seule décision apparaît sous forme de plusieurs changements.
Un commentaire qui mentionne quelqu'un. La personne @mentionnée reçoit déjà « Vous avez reçu une mention ». Lui envoyer « Nouveau commentaire » pour le même commentaire ferait doublon, donc elle ne reçoit que la mention.
Une rafale de tri. Le tri est rarement une seule modification. Vous réglez la priorité, ajoutez deux étiquettes et choisissez une échéance, le tout en moins d'une minute, et l'éditeur d'étiquettes enregistre à chaque clic. Avec trois personnes sur la tâche, cela fait douze notifications pour ce qui ressemblait à une seule décision.
Les modifications de propriétés d'une même personne sur une même tâche ne comptent donc qu'une fois toutes les cinq minutes. Chaque destinataire reçoit un seul « Alex Rivera a modifié Priorité sur AS-3 » pour toute la rafale. Un changement fait par quelqu'un d'autre entre-temps est toujours notifié séparément.
C'est aussi pour ça que la notification nomme la propriété et pas la valeur. « A passé Priorité à Haute » devient faux dès que le clic suivant la met à Critique, et un e-mail ne se corrige plus une fois envoyé. La formule « a modifié Priorité » reste vraie, et la valeur actuelle est à un clic.
Une action groupée. Déplacer 30 tâches dans Terminé, c'est aussi une seule décision. Chaque personne reçoit une notification avec le nombre de tâches, et son bouton ouvre le tableau plutôt qu'une tâche.
Le nombre couvre toute l'action, pas seulement les tâches dans lesquelles cette personne est impliquée. Compter par personne aurait obligé à attendre que chaque tâche du lot soit traitée, et je n'ai pas jugé que la précision valait ce délai.
Ce que j'ai laissé de côté
Un récapitulatif. Regrouper les e-mails en un résumé horaire ou quotidien a l'air attentionné. En réalité, cela retient le seul message urgent pour qu'il arrive avec cinq qui ne l'étaient pas. BugDump envoie un e-mail par changement, avec la fenêtre de cinq minutes sur les modifications de propriétés comme seule exception. Si cela fait trop d'e-mails pour quelqu'un, il peut désactiver l'e-mail et tout garder dans la cloche.
Une matrice de réglages. Une grille des types d'événements par canal a l'air complète. La plupart des gens ne l'ouvrent jamais, et ceux qui l'ouvrent finissent par presque tout désactiver. Bien choisir les destinataires fait plus qu'une page de réglages.
Les changements dont personne n'a besoin d'entendre parler. Modifier un titre, faire passer une colonne d'ouverte à fermée dans les réglages du tableau, supprimer une tâche. Aucun ne passe le test « ferait-il quelque chose différemment », donc aucun ne déclenche de notification.
Comment ça marche dans BugDump
Il y a quatre notifications de tâches : Une tâche vous a été assignée, Nouveau commentaire, Statut modifié et Propriété modifiée. Elles apparaissent dans la cloche et partent par e-mail dans la langue de chaque personne, sur tous les forfaits, Gratuit compris.
Une notification de commentaire cite le début du commentaire, si bien que la notification seule suffit souvent à savoir s'il faut ouvrir la tâche.
Les règles complètes, y compris tout ce qui n'envoie pas de notification, sont dans le centre d'aide : Notifications de tâches : qui est prévenu d'un changement.
Pour aller plus loin
Champs personnalisés dans un bug tracker : quoi ajouter, et à quoi résister — quels champs méritent une place sur une tâche, et lesquels finissent vides.
Les métriques de suivi des bugs qui comptent vraiment — les quelques chiffres qui disent si votre suivi de bugs fonctionne.
Trier les bugs plus vite avec un workflow au clavier — comment traiter une file de nouveaux rapports sans quitter le clavier.