Der erste Bug in einem brandneuen Projekt sollte die Nummer eins tragen. Meistens tut er das nicht.
Die meisten Tools, die mit einem einzigen gemeinsamen Zähler starten, behalten ihn, weil es am Anfang nur ein Projekt gibt und der Unterschied nicht auffällt. Dann kommt das zweite Team dazu, legt sein erstes Projekt an, erfasst seinen ersten Bug, und der bekommt die Nummer #913. Kaputt ist nichts. Es liest sich nur so, als wäre man in ein fremdes Gebäude geraten.
Ich habe diese Woche in BugDump die Nummerierung pro Projekt eingeführt, und die Überlegungen dahinter gelten weit über mein Produkt hinaus. Eine Bug-ID gehört zu den wenigen Teilen deines Datenmodells, die Leute laut aussprechen, und das ändert, worin sie gut sein muss.
Was ein globaler Zähler wirklich kostet
Er verrät Daten. Eine Nummer aus einer gemeinsamen Sequenz zeigt allen, die sie lesen, ungefähr, wie viel Traffic das ganze System hat. Zwei Bugs, die in deinem Projekt im Abstand von einem Monat erfasst wurden, verraten, wie viele Bugs alle anderen dazwischen erfasst haben. Das ist dieselbe Art Problem wie bei Rechnungsnummern aus einem einzigen globalen Zähler, und deshalb nutzen Rechnungstools keinen solchen Zähler mehr.
Er liest sich wie Rauschen. #913 bedeutet nichts für die Person, die es sieht. Es ist nicht der 913. Bug in irgendetwas, das sie sehen kann. Die Zahl ist zu groß, um sie sich leicht zu merken, und zu beliebig, um sie auf Plausibilität zu prüfen.
Er verschenkt ein kostenloses Signal. Bei Nummerierung pro Projekt ist die Nummer zugleich eine grobe Zählung. BD-6 heißt, das Projekt hatte eine Handvoll Bugs. BD-2400 heißt etwas ganz anderes, und das erfährst du, ohne ein Dashboard zu öffnen.
Nichts davon ist ein Beinbruch. Viele gute Tools liefern jahrelang einen globalen Zähler aus. Aber es ist eine kleine Steuer auf jede einzelne ID, für immer, und die Lösung ist billig.
Warum sich das Präfix lohnt
Nummerierung pro Projekt schafft ein neues Problem: Nummern sind nicht mehr eindeutig. Aufgabe 42 gibt es in jedem deiner Projekte.
Der Pfad in der URL löst das bereits, denn er enthält das Projekt. Aber ein Gespräch hat keine URL. Jemand schreibt „Kannst du dir mal 42 ansehen?“ in einen Channel, in dem es um drei Projekte geht, und der Satz ist tatsächlich mehrdeutig.
Ein kurzer Schlüssel vor der Nummer behebt das genau dort, wo Mehrdeutigkeit überhaupt entsteht: im Gespräch zwischen Menschen. BD-42 ist eindeutig, 42 nicht, und das kostet drei Zeichen. Jira liegt damit seit zwanzig Jahren richtig, und Linear, Shortcut und Sentry sind unabhängig voneinander an derselben Stelle gelandet.
Der Schlüssel sollte abgeleitet werden, nicht abgefragt. Beim Registrieren einen Projektschlüssel erfinden zu müssen, ist eine kleine Steuer in einem Moment, in dem man eigentlich etwas anderes vorhat. Leite ihn aus dem Projektnamen ab, aus Bug Dump wird BD, und lass ihn später in den Einstellungen ändern. Die meisten tun das nie.
Die drei Designentscheidungen, auf die es ankommt
Sobald du dich auf Nummern pro Projekt mit Präfix festgelegt hast, entscheiden drei Fragen, ob das Ergebnis angenehm oder lästig wird.
1. Werden Nummern nach dem Löschen wiederverwendet?
Nein. Das dürfen sie nie.
Wenn das Löschen der neuesten Aufgabe ihre Nummer für die nächste freigibt, kann ein Link, eine Commit-Message oder ein Slack-Thread, der auf BD-9 verweist, unbemerkt auf einen anderen Bug zeigen. Der Fehler ist leise und kann beliebig spät auftreten, die schlimmste Kombination.
Führ einen Zähler, der nur steigt. Lücken in der Folge sind kein Mangel. Sie sind der sichtbare Beweis, dass alte Verweise noch das bedeuten, was sie gesagt haben.
2. Ist das Präfix Teil der Adresse oder Dekoration?
Das ist die spannende Frage, und beide Antworten lassen sich vertreten.
Ist das Präfix Dekoration, sind BD-42 und 42 zwei Schreibweisen derselben Adresse, und beide öffnen die Aufgabe. Einen Projektschlüssel umzubenennen kostet dann nichts: Die Labels ändern sich überall, Links funktionieren weiter, niemand merkt etwas.
Ist das Präfix Teil der Adresse, funktioniert nur das exakte aktuelle Label. Eine Umbenennung des Schlüssels macht jeden Link mit dem alten kaputt.
Ich habe mich bewusst für die zweite Variante entschieden, nachdem ich mit der ersten angefangen hatte. Den Ausschlag gab dieses Argument: Eine URL mit einem Präfix, das nicht der Schlüssel dieses Projekts ist, ist in jedem realistischen Fall ein Fehler. Jemand hat einen Link aus dem falschen Projekt eingefügt, sich vertippt oder folgt einem veralteten Verweis. Dann irgendeine Aufgabe zu öffnen, die in diesem Projekt zufällig diese Nummer trägt, hilft niemandem. Es sieht aus, als hätte es funktioniert, und zeigt still den falschen Bug.
Deshalb bekommt ein falsches Präfix ein 404, genauso wie eine aufgefüllte Nummer wie BD-007 und eine Nummer, die keine Aufgabe trägt. Die Nummer ohne Präfix bleibt eine dauerhafte Adresse, die keine Umbenennung kaputtmachen kann, und sie ist die Form, die das Produkt in jeden Link, jede E-Mail und jeden Webhook-Payload schreibt, den es erzeugt.
Der Preis ist real, also sage ich es offen: Benennst du einen Schlüssel um, funktionieren Links mit dem alten nicht mehr. Das nehme ich in Kauf, damit niemand je den falschen Bug sieht.
3. Funktionieren beide Formen überall?
Das sollten sie. Leute kopieren das Label, das sie sehen, nicht das, mit dem deine App zufällig verlinkt.
Wenn deine Oberfläche auf einer Karte BD-42 anzeigt, muss BD-42 auch in der Adressleiste funktionieren. Sonst hast du eine kleine Falle für alle gebaut, die das Naheliegende tun. Akzeptier beide Schreibweisen, behalte die bei, mit der jemand gekommen ist, und erzeuge die kanonische selbst.
Was eine Zahl bleibt
Das Präfix ist für Menschen. Maschinen sollten weiter Ganzzahlen bekommen.
Webhook-Payloads, API-Antworten und Argumente von MCP-Tools enthalten in BugDump weiterhin die Nummer, mit dem Anzeige-Label daneben als eigenem Feld. Nichts, was einen Payload schon parst, musste sich ändern, und niemand muss einen Parser für ein String-Format schreiben, um herauszufinden, auf welchen Bug sich ein Event bezieht.
Diese Trennung solltest du beim Bauen bewusst bewahren. Das Label ist eine Frage der Darstellung. Sobald es in deine Integrationsverträge sickert, wird das Umbenennen eines Projektschlüssels zu einem Breaking Change der API, und eine kosmetische Einstellung wird zu etwas, das sich niemand mehr anzufassen traut.
Migrieren, ohne zu zerstören, was schon verschickt wurde
Der unangenehme Teil beim Ausliefern: IDs existieren bereits und sind im Umlauf, in E-Mails, Chatverläufen und den Tickets anderer Leute.
Bestehende Aufgaben neu zu nummerieren, damit jedes Projekt ordentlich bei 1 anfängt, ist verlockend und falsch. Jeder alte Verweis zeigt dann unbemerkt woandershin. Die Alternative ist langweiliger und richtig: Bestehende Nummern bleiben, wie sie sind, der Zähler jedes Projekts startet über seiner eigenen höchsten Nummer, und alte Projekte behalten für immer lückenhafte IDs. Neue Projekte zählen sauber ab 1, alte Links bedeuten weiter, was sie bedeutet haben, und niemandem muss man etwas erklären.
Nummerierung ist ein kleines Feature. Aber jede Person im Team fasst es dutzendmal am Tag an. Das ist ein gutes Argument dafür, einen Nachmittag zu investieren und es richtig zu machen, statt auf unbestimmte Zeit mit #913 zu leben.
Der Maschinenname, der zugleich der Anzeigename war – was passierte, als Prioritäten editierbar wurden und ihr stabiler Schlüssel längst auch an die Clients ging.
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.
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 von dir kommen müssen.