Veröffentliche etwas für ein paar Tausend Leute, und als Erstes lernst du, dass Fehlerberichte nicht einer pro Bug eintreffen.
Ein einziger kaputter Checkout erzeugt an einem Nachmittag vierzig Berichte. Naiv behandelt sind das vierzig Einträge zum Lesen, vierzig zum Einordnen und neununddreißig, die du als Duplikat schließt. Der geschäftigste Tag deines Bug-Trackers liefert die wenigsten Informationen.
Berichte und Aufgaben sind verschiedene Dinge
BugDump hält sie getrennt, und auf dieser strukturellen Entscheidung beruht alles andere.
Ein Bericht ist eine Einsendung von einer Person zu einem Zeitpunkt: ihre Beschreibung plus alles, was das SDK erfasst hat. Berichte sind unveränderliche Belege. Sie werden nie bearbeitet, nie zusammengeführt, nie dedupliziert.
Eine Aufgabe ist das, was du behebst. Sie hat eine öffentliche ID, eine Spalte auf dem Board, Kommentare und einen Aktivitätsverlauf.
Viele Berichte hängen an einer Aufgabe. Vierzig Berichte zum Checkout werden zu einer Aufgabe mit vierzig Belegen.
Die Unterscheidung ist keine Buchhaltung. Sie bildet etwas ab, das tatsächlich so ist: Belege und Arbeit sind verschiedene Objekte mit verschiedenen Lebenszyklen. Belege sammeln sich an und ändern sich nie. Arbeit durchläuft Zustände und endet irgendwann. Systeme, die beides vermischen, zwingen dich, dich für eins zu entscheiden: Entweder du verlierst Belege, weil du Duplikate zusammenführst, oder du gehst in Einträgen unter, weil jeder Beleg auch eine Aufgabe ist.
Duplikate sind ein Gewinn
Sobald Berichte an Aufgaben hängen, sind Duplikate kein Rauschen mehr. Sie werden zu deinem besten Signal fürs Debugging.
Vierzig Berichte an einer Aufgabe geben dir etwas, das kein einzelner Bericht liefern kann: die Schnittmenge.
Kommen alle vierzig aus Safari, ist es ein Safari-Bug, und das weißt du, bevor du einen Debugger öffnest. Verteilen sie sich auf alle Browser, haben aber einen Viewport unter 768 px gemeinsam, liegt es am responsiven Layout. Häufen sie sich in einem Fenster von fünfzehn Minuten und hören dann auf, war es ein Deployment, und du solltest dir ansehen, was ausgeliefert wurde, statt deinen Code zu durchsuchen.
Diese Analyse dauert Sekunden, wenn Berichte gruppiert sind, und ist fast unmöglich, wenn es vierzig einzelne Einträge in einer Liste sind. Die häufigste Form eines echten Vorfalls, bei der viele Leute auf dieselbe Sache stoßen, ist genau die, mit der ein flacher Posteingang am schlechtesten umgehen kann.
Hier zahlt sich auch der MCP-Server aus. „Lies die Berichte zu #17 und sag mir, welche Browser betroffen sind“ ist eine Frage, die ein Agent in Sekunden beantwortet, weil er alle vierzig liest. Berichte miteinander zu vergleichen ist so mühsam, dass Menschen es auslassen, und genau deshalb lohnt es sich, es zu automatisieren.
Das Board
Aufgaben liegen auf einem Kanban-Board mit Spalten, die du selbst festlegst. Jede Spalte gehört zu einem von zwei Zuständen: offen oder geschlossen.
Entscheidend ist diese Zuordnung, nicht der Name. Du könntest zum Beispiel so arbeiten:
Triage → Bestätigt → In Arbeit → Fertig → Wird nicht behoben
Dabei sind die ersten drei open und die letzten zwei closed. Oder du machst etwas ganz anderes: Durch das Modell mit zwei Zuständen weiß das System, was als offen zählt, egal wie du deine Spalten nennst.
Zwei Zustände, nicht fünf. Jede Einteilung nach dem Muster „Zurückgestellt / Blockiert / Infos fehlen / Wartet auf Rückmeldung“, die ich gesehen habe, endet gleich: mit einer Spalte voller Aufgaben, die sich niemand mehr ansieht. Ist eine Aufgabe nicht erledigt, ist sie offen, und offene Arbeit sollte sichtbar sein.
Dass Wird nicht behoben zu closed gehört, ist ebenfalls Absicht. Zu entscheiden, etwas nicht zu beheben, ist ein echter Abschluss. Die Aufgabe sollte deine offene Warteschlange verlassen.
Eine Triage-Routine, die funktioniert
Lies die neuen Berichte und gruppiere sie. Die meisten sind Duplikate. Häng sie an bestehende Aufgaben. Das sind die zehn Minuten mit der größten Hebelwirkung im ganzen Prozess: Aus vierzig Einträgen werden sechs.
Leg Aufgaben für das an, was wirklich neu ist. Eine pro eigenständigem Bug.
Nutze die Schnittmenge. Schau dir bei jeder Aufgabe mit mehreren Berichten an, was sie gemeinsam haben, bevor du in den Code schaust.
Verschieben statt kommentieren. Die Position auf dem Board ist der Status. Eine Aufgabe in In Arbeit mit dem Kommentar „eigentlich blockiert“ steht in der falschen Spalte.
Schließ Aufgaben. Auch die, die du nicht beheben wirst.
Den Kreis schließen
Jedes Projekt kann unter your-project.bugdump.com ein öffentliches Portal veröffentlichen, auf dem alle, die etwas gemeldet haben, ihre Aufgaben verfolgen.
Diesen Teil lassen die meisten Tools aus, und genau er entscheidet, ob du weiter Berichte bekommst.
Wer einen Bug meldet und nichts mehr hört, schließt daraus, dass Melden nichts bringt. Das ist ein vernünftiger Schluss aus dem, was die Person sehen kann. Wenn das nächste Mal etwas kaputtgeht, umgeht sie es stillschweigend, und dir fehlt das Signal.
Wer zusieht, wie die eigene Aufgabe von Bestätigt nach Fertig wandert, hat das Gegenteil gelernt und meldet den nächsten Bug und den danach auch.
Du kannst Meldende auch selbst Berichte an eine Aufgabe hängen lassen. Mit aktiviertem allowTaskAttach reicht jemand, der die öffentliche ID einer Aufgabe kennt, den Bericht direkt zu dieser Aufgabe ein. Für interne QA- und Betagruppen, die deine Aufgaben-IDs ohnehin kennen, entfällt damit deine Triage komplett: Sie gruppieren ihre Duplikate selbst.
Die Kurzfassung
Berichte sind Belege. Aufgaben sind Arbeit. Halte sie getrennt, lass Duplikate sich als Belege ansammeln, statt gegen sie anzukämpfen, beschränke das Board auf zwei echte Zustände und zeig den Meldenden, was passiert ist.
Aus vierzig Berichten werden sechs Bugs, und die sechs kommen mit besseren Belegen, als ein einzelner Bericht sie je liefern könnte.
Bugs schneller triagieren: ein Workflow für die Tastatur – ein Triage-Workflow, der dir die Navigation rund um jede Entscheidung abnimmt, statt schnelleres Denken zu verlangen.
Prioritätsstufen für Bugs: warum vier feste Stufen nie passen – wofür eine Prioritätsskala da ist, wie viele Stufen du brauchst und warum die Namen deine eigenen sein müssen.
Benachrichtigungen im Bug-Tracker: Wer soll von einer Änderung erfahren? – wie BugDump aus der Aufgabe selbst ableitet, wer Bescheid bekommt, und mehrere Triage-Klicks in einer Nachricht bündelt.