Benachrichtigungen im Bug-Tracker gehen in zwei Richtungen schief. Schickst du zu wenige, erfährst du am Donnerstag, dass der Bug, an dem du arbeitest, schon am Montag jemand anderem zugewiesen wurde. Schickst du zu viele, haben am dritten Tag alle einen Mailfilter und einen Ordner, den sie nie öffnen. Das Ergebnis ist in beiden Fällen dasselbe. Die Leute vertrauen dem Kanal nicht mehr, und die eine Benachrichtigung, auf die es ankam, bleibt ungelesen.
Ich habe gerade Aufgaben-Benachrichtigungen in BugDump veröffentlicht. Das Versenden war der einfache Teil. Die meiste Arbeit steckte in der Entscheidung, wer eine bekommen soll und wann es besser ist, nichts zu sagen. Hier sind die Regeln, bei denen ich gelandet bin, und die Gründe dahinter.
Mit einer Frage anfangen
Frag dich bei jeder Benachrichtigung: Würde diese Person deswegen irgendetwas anders machen?
Die Person, die eine Aufgabe umsetzt, die QA gerade als gelöst markiert hat: ja, sie hört auf, daran zu arbeiten. Die Person, die den Bug gemeldet hat: ja, sie kann den Fix prüfen. Wer vor einem Monat kurz auf die Aufgabe geschaut hat: nein. Dieser Person die Nachricht trotzdem zu schicken, kostet mehr als eine verschwendete E-Mail. Sie lernt daraus, dass die Glocke vor allem Rauschen bringt, und liest die nächste Nachricht mit etwas weniger Aufmerksamkeit.
Alles Weitere folgt aus dieser Frage.
Wer benachrichtigt wird, ergibt sich aus der Aufgabe
Die meisten Tracker beantworten „Wer erfährt davon?“ mit Beobachtungslisten. Du klickst auf „Beobachten“ und bekommst alles. Das klingt flexibel. In der Praxis veralten diese Listen. Leute vergessen, die Aufgabe zu beobachten, die ihnen wichtig ist, und stehen noch auf denen, die ihnen seit Monaten egal sind. Eine Liste, die jemand von Hand pflegen muss, ist meist nicht aktuell.
Also gibt es bei mir keine. Wenn sich eine Aufgabe ändert, liest BugDump aus ihrem aktuellen Stand ab, wer beteiligt ist:
wer sie erstellt hat,
wer für sie zuständig ist,
alle, die in einem Mitgliedsfeld stehen, etwa Review oder QA-Verantwortung,
alle, die sie kommentiert haben.
Kommentieren ist das stärkste Signal der vier. Wer sich die Zeit nimmt, etwas zu einer Aufgabe zu schreiben, sagt dir, ohne es auszusprechen: Ich will wissen, wie das ausgeht.
Ein Mitgliedsfeld ist die bewusste Variante. Wenn jemand aus dem Design einen Bug verfolgen soll, trag die Person ins Feld Review ein. Sie erfährt vom nächsten Kommentar und vom nächsten Statuswechsel, und wenn du sie wieder austrägst, hört das auf. Niemand muss daran denken, sich abzumelden, und wer das Projekt verlässt, fällt auf einen Schlag aus allen Aufgaben des Projekts heraus.
Der Preis dafür: Du kannst keiner Aufgabe folgen, an der du nicht beteiligt bist. Ich habe entschieden, dass ich damit leben kann, bis tatsächlich jemand danach fragt.
Keine Benachrichtigung über das, was du gerade selbst getan hast
Das klingt zu offensichtlich, um es aufzuschreiben. Weniger offensichtlich wird es, sobald KI-Agenten im Spiel sind.
Wenn dein Agent mit deinem MCP-Token eine Aufgabe nach „Fertig“ verschiebt, ist das deine Aktion. Dich darüber zu benachrichtigen ist Rauschen, du hast es ja selbst angestoßen. Deine Teammitglieder sollten trotzdem davon erfahren und erkennen können, dass nicht du geklickt hast, deshalb steht in ihrer Benachrichtigung Alex Rivera via MCP.
Eine Änderung, eine Benachrichtigung
Schwierig waren die Fälle, in denen eine einzige Entscheidung als mehrere Änderungen auftaucht.
Ein Kommentar, der jemanden erwähnt. Die per @ erwähnte Person bekommt schon „Du wurdest erwähnt“. Ihr für denselben Kommentar zusätzlich „Neuer Kommentar“ zu schicken, wäre doppelt, also bekommt sie nur die Erwähnung.
Eine Serie von Triage-Klicks. Triage ist selten eine einzige Änderung. Du setzt die Priorität, fügst zwei Labels hinzu und wählst ein Fälligkeitsdatum, alles innerhalb einer Minute, und der Label-Editor speichert bei jedem Klick. Mit drei Leuten an der Aufgabe sind das zwölf Benachrichtigungen für etwas, das sich wie eine Entscheidung angefühlt hat.
Deshalb zählen die Eigenschaftsänderungen einer Person an einer Aufgabe nur einmal alle fünf Minuten. Alle Beteiligten bekommen für die ganze Serie eine einzige Nachricht „Alex Rivera hat Priorität bei AS-3 geändert“. Ändert in der Zwischenzeit jemand anderes etwas, wird das weiterhin einzeln gemeldet.
Aus demselben Grund nennt die Benachrichtigung die Eigenschaft und nicht den Wert. „Hat Priorität auf Hoch geändert“ ist falsch, sobald der nächste Klick sie auf Kritisch setzt, und eine E-Mail lässt sich nach dem Versand nicht mehr korrigieren. „Hat Priorität geändert“ bleibt wahr, und der aktuelle Wert ist einen Klick entfernt.
Eine Massenaktion. 30 Aufgaben nach „Fertig“ zu verschieben, ist auch eine Entscheidung. Jede Person bekommt eine Benachrichtigung mit der Anzahl, und ihr Button öffnet das Board statt einer einzelnen Aufgabe.
Die Anzahl umfasst die ganze Aktion, nicht nur die Aufgaben, an denen die jeweilige Person beteiligt ist. Pro Person zu zählen hätte bedeutet, zu warten, bis jede Aufgabe des Stapels verarbeitet ist, und diese Genauigkeit war mir die Verzögerung nicht wert.
Was ich weggelassen habe
Ein Digest. E-Mails in einer stündlichen oder täglichen Zusammenfassung zu sammeln, klingt rücksichtsvoll. Tatsächlich hält es die eine dringende Nachricht zurück, damit sie zusammen mit fünf nicht dringenden ankommt. Ich schicke eine E-Mail pro Änderung, mit dem Fünf-Minuten-Fenster für Eigenschaftsänderungen als einziger Ausnahme. Wenn das für jemanden zu viele E-Mails sind, lassen sie sich abschalten, und alles bleibt in der Glocke.
Eine Einstellungsmatrix. Ein Raster aus Ereignistypen und Kanälen wirkt gründlich. Die meisten öffnen es nie, und wer es öffnet, schaltet meist fast alles ab. Die richtigen Leute zu benachrichtigen bringt mehr, als eine Einstellungsseite leisten kann.
Änderungen, von denen niemand erfahren muss. Einen Titel bearbeiten, eine Spalte in den Board-Einstellungen zwischen offen und geschlossen umschalten, eine Aufgabe löschen. Keine davon besteht den Test „Würde jemand deswegen etwas anders machen?“, also löst keine eine Benachrichtigung aus.
So funktioniert es in BugDump
Es gibt vier Aufgaben-Benachrichtigungen: „Dir zugewiesen“, „Neuer Kommentar“, „Status geändert“ und „Eigenschaft geändert“. Sie erscheinen in der Glocke und gehen per E-Mail in der Sprache der jeweiligen Person raus, in jedem Plan, auch im kostenlosen.
Eine Kommentar-Benachrichtigung zitiert den Anfang des Kommentars, sodass du oft schon an der Benachrichtigung siehst, ob du die Aufgabe öffnen musst.
Die vollständigen Regeln, auch alles, was keine Benachrichtigung auslöst, stehen im Hilfe-Center: Aufgaben-Benachrichtigungen: wer von einer Änderung erfährt.
Benutzerdefinierte Felder im Bug-Tracker: was sich lohnt und was nicht – der Test, der ein nützliches Feld von einem trennt, das in sechs Wochen leer ist, und die vier Felder, die sich auszahlen.
Bug-Tracking-Metriken, die wirklich zählen – vier Kennzahlen, die zeigen, ob dein Team mit den Bugs Schritt hält, und ein wöchentlicher Check in fünf Minuten.
Bugs schneller triagieren: ein Workflow für die Tastatur – wie Triage schneller wird, wenn die Navigation drumherum wegfällt, nicht das Nachdenken.