Ein einzelnes Plugin lässt sich noch mit einer einfachen Liste von Fehlermeldungen verwalten. Sobald mehrere Produkte, interne Projekte oder Varianten hinzukommen, wird die Zuordnung zum entscheidenden Ordnungsprinzip. Ohne sie vermischen sich Versionsangaben, Zuständigkeiten und Entwicklungsentscheidungen. Der CROPS Bugtracker behandelt Produkte deshalb nicht als bloßes Textfeld, sondern als eigenständigen Verwaltungsbereich.
Ein Produkt ist mehr als ein Name
Für die Zuordnung benötigt jedes Produkt eine klare Bezeichnung und einen eindeutigen Slug. Der Name ist für Menschen lesbar, der Slug bildet eine stabile technische Referenz. Dadurch können Filter, interne Verknüpfungen und spätere Importe zuverlässig auf denselben Eintrag verweisen, selbst wenn die sichtbare Bezeichnung angepasst wird.
Diese Trennung ist besonders bei einer langfristigen Produktentwicklung wichtig. Ein Plugin kann umbenannt oder präziser bezeichnet werden, ohne dass ältere Bugreports ihren Bezug verlieren. Bestehende Namen sollen bei Updates außerdem nicht ungefragt überschrieben werden. Manuelle Anpassungen des Betreibers haben Vorrang vor mitgelieferten Ausgangsdaten.
Die neutrale Verkaufsversion startet bewusst leer
Für eine allgemein nutzbare Version wäre eine fest eingebaute Liste interner CROPS-Produkte ungeeignet. Käufer des Bugtrackers betreuen eigene Plugins und Projekte. Die neutrale Verkaufsversion enthält daher keine internen Produktvorgaben. Der Betreiber legt nur die Einträge an, die für seinen tatsächlichen Einsatz erforderlich sind.
Dieser Ansatz hält die Installation sauber und verhindert Verwirrung. Ein Agenturteam kann Kundenprojekte eintragen, ein Plugin-Anbieter seine Erweiterungen und ein internes Entwicklungsteam seine Module. Die gleiche technische Grundlage bleibt erhalten, ohne fremde Produktnamen oder Projektstrukturen vorzugeben.
Die interne Edition bildet vorhandene Projekte ab
Innerhalb der CROPS-Entwicklung gelten andere Anforderungen. Dort soll die Produktliste nur Projekte enthalten, die tatsächlich vorhanden sind. Produktname und Projektname sollen zusammenpassen. Projektchat-Adressen werden nur dort eingetragen, wo eine bekannte Adresse vorliegt; fehlende Verknüpfungen bleiben bewusst leer und werden nicht erfunden.
Diese Vorsicht schützt vor falschen Weiterleitungen. Ein Button zum Öffnen des Projektarbeitsbereichs ist nur hilfreich, wenn er auf das richtige Ziel verweist. Deshalb ist eine unvollständige, aber verlässliche Zuordnung besser als eine automatisch gefüllte Liste mit unsicheren Daten.
Der Produktbezug strukturiert die tägliche Arbeit
Ist jedes Ticket einem Produkt zugeordnet, kann die Verwaltung gezielt gefiltert werden. Der Betreiber sieht beispielsweise nur Meldungen zu einem bestimmten Plugin, prüft offene Berichte für ein bevorstehendes Release oder untersucht, ob mehrere Käufer dasselbe Verhalten beschrieben haben.
Auch die Priorisierung wird verständlicher. Ein kritischer Fehler in einem zentralen Produkt kann anders behandelt werden als eine geringe Darstellungsabweichung in einem optionalen Modul. Die Produktzuordnung liefert den Kontext, in dem Status und Priorität sinnvoll interpretiert werden.
Projektverknüpfungen verkürzen den internen Weg
Der Bugreport bleibt die verbindliche Dokumentation des Vorgangs. Für die eigentliche Analyse kann es jedoch sinnvoll sein, den Bericht in den passenden Projektarbeitsbereich zu übernehmen. Der CROPS Bugtracker unterstützt diesen Schritt durch eine gespeicherte Projektchat-Adresse und eine Kopierfunktion. Der Mitarbeiter öffnet das richtige Projekt und übergibt die strukturierten Angaben bewusst.
Damit entsteht keine undurchsichtige Vollautomatik. Der Betreiber behält Kontrolle darüber, welche Informationen weitergegeben werden. Die Rückmeldung aus der Analyse kann anschließend als interne Notiz oder Statusentscheidung im Bugreport dokumentiert werden.
Update-Sicherheit ist Teil der Produktverwaltung
Eine Produktliste gewinnt mit der Zeit an Wert. Sie enthält angepasste Namen, interne Links und den Bezug zu zahlreichen Tickets. Ein Update darf diese Daten nicht löschen oder durch neue Ausgangswerte ersetzen. Für die interne wie die neutrale Edition gilt deshalb das Prinzip, vorhandene Produkte, Projektchat-Adressen, Tickets, Anhänge, Protokolle und Einstellungen zu erhalten.
Neue Standardwerte dürfen nur ergänzen, was noch nicht vorhanden ist, und müssen sich an der jeweiligen Edition orientieren. Die Verkaufsversion darf keine internen Datensätze nachladen. Die interne Version darf bekannte Projekte ergänzen, aber keine vom Betreiber bearbeiteten Einträge zurücksetzen.
Ein kleines Modul mit großer Wirkung
Die Produktverwaltung wirkt auf den ersten Blick unspektakulär. Tatsächlich entscheidet sie darüber, ob ein wachsender Bugtracker übersichtlich bleibt. Sie verbindet öffentliche Meldung, interne Prüfung und projektbezogene Weiterarbeit.
Mit klaren Namen, stabilen Slugs, vorsichtigen Projektverknüpfungen und update-sicherer Speicherung entsteht ein belastbares Fundament. Jeder Bugreport erhält den richtigen fachlichen Kontext, und der Betreiber kann mehrere Produkte verwalten, ohne dass die zentrale Liste zu einem ungeordneten Sammelplatz wird.
Ein Beispiel für stabile Zuordnung
Angenommen, ein Plugin erhält im Laufe der Entwicklung einen präziseren Produktnamen. Der sichtbare Name kann angepasst werden, während der bestehende Slug und die Verknüpfungen zu älteren Bugreports erhalten bleiben. Filter zeigen weiterhin sämtliche Vorgänge des Produkts, und die bekannte Projektadresse bleibt verfügbar. Genau dieser Zusammenhang macht eine eigenständige Produktverwaltung sinnvoll. Würde der Name nur als freier Text in jedem Bericht stehen, entstünden schnell Varianten und Tippfehler. Der zentrale Datensatz sorgt dagegen für Konsistenz und lässt trotzdem kontrollierte Änderungen zu. Damit bleibt die Zuordnung auch über mehrere Releases hinweg verständlich.
Auch Auswertungen werden dadurch belastbarer, weil gleiche Produkte nicht unter mehreren Schreibweisen erscheinen.
