Der CROPS Bugtracker hat sich von einer Produktidee zu einem klar abgegrenzten WordPress-Werkzeug entwickelt. Im Mittelpunkt steht weiterhin die strukturierte Fehlermeldung für Entwickler, Plugin-Anbieter und Agenturen. Das Projekt soll kein allgemeines Helpdesk ersetzen, sondern den Weg vom Käuferhinweis bis zur dokumentierten Entwicklungsentscheidung zuverlässig abbilden.
Der fachliche Kern steht fest
Das Meldeformular erfasst Produkt oder Plugin, Produktversion, Fehlerüberschrift, Beschreibung, Schritte zur Reproduktion, erwartetes und tatsächliches Verhalten, Häufigkeit, WordPress- und PHP-Version, aktives Theme, relevante Plugins, Browser oder Gerät sowie Screenshots, Logs und zusätzliche Hinweise. Diese Struktur bildet die Grundlage für eine nachvollziehbare Prüfung.
Im Adminbereich werden Meldungen nach Produkt, Status und Priorität organisiert. Die Qualitätsbewertung von 0 bis 100 zeigt, wie vollständig die Angaben sind. Sie ersetzt keine fachliche Entscheidung, hilft aber bei der ersten Sichtung und bei gezielten Rückfragen.
Ein differenzierter Lebenszyklus für Bugreports
Die Statuswerte decken den tatsächlichen Entwicklungsprozess ab: neu, in Prüfung, Rückfrage, bestätigt, geplant, in Arbeit, behoben, im nächsten Release, geschlossen, abgelehnt, Dublette oder archiviert. Ergänzende Zustände wie nicht reproduzierbar oder veröffentlicht können den Ablauf weiter präzisieren.
Prioritäten von niedrig bis sicherheitsrelevant ordnen die Dringlichkeit. Die Historie dokumentiert wichtige Aktionen, darunter Status- und Prioritätsänderungen, interne Notizen, Downloads, Kopiervorgänge, Projektchat-Öffnungen, Dublettenverbindungen, Zusammenführungen, Archivierung und Löschung.
Belohnungen bleiben bewusst einfach
Der eigene Bereich „Belohnungen“ ist Teil des aktuellen Konzepts. Der Betreiber pflegt Name, Beschreibung, Link, Code, optionales Ablaufdatum, E-Mail-Text, Status und interne Notiz. Eine aktive Belohnung kann direkt im geprüften Bugreport ausgewählt und manuell vergeben werden.
Versanddatum, verantwortliche Person und Historie sorgen für Nachvollziehbarkeit. Link und Code können bei Bedarf erneut gesendet werden. Auf Shop-, Download-, Referral- oder Auszahlungsschnittstellen wird bewusst verzichtet. Dadurch bleibt das Modul verständlich und unabhängig.
Produktverwaltung für interne und externe Nutzung
Die neutrale Verkaufsversion startet ohne interne Produktdaten. Käufer legen ihre eigenen Plugins und Projekte an. Die interne Edition kann dagegen die tatsächlich vorhandenen CROPS-Projekte mit bekannten Slugs und Projektchat-Adressen abbilden. Unbekannte Adressen werden nicht erfunden.
Vorhandene Produktnamen, Tickets, Anhänge, Logs, Einstellungen, Projektverknüpfungen und Schlüssel dürfen bei Updates nicht überschrieben oder gelöscht werden. Diese Update-Sicherheit ist ein verbindlicher Bestandteil der weiteren Release-Prüfung.
RC22 verbessert den konkreten Arbeitsalltag
Die neutrale Verkaufsversion wurde bis RC22 weitergeführt. Ein wichtiger Schwerpunkt war die Produktverwaltung. Bei kleineren Breiten und Browser-Zoom wechselt die Liste in einen Kartenmodus, in dem Aktionsbuttons sichtbar unter Produktname und Slug stehen. Der Editor stapelt sich unter der Liste, statt beide Bereiche zu quetschen.
„Neues Produkt“ und „Bearbeiten“ werden per JavaScript auf derselben Seite als Modal geöffnet. Die Speicherung erfolgt per AJAX. Ein klassischer Link bleibt nur als Fallback für deaktiviertes JavaScript. Diese Korrektur beseitigt unerwünschte Seitenwechsel und verbessert die Nutzung auf Mobilgeräten sowie bei 150 Prozent Zoom.
Der Projektchat ist eingebunden, aber nicht erzwungen
Produkte können mit einem passenden Projektarbeitsbereich verbunden werden. Der Bearbeiter kopiert den strukturierten Bericht und öffnet den hinterlegten Projektchat. Es gibt keine feste externe API-Abhängigkeit. Die Weitergabe bleibt bewusst kontrolliert, und die Ergebnisse werden anschließend im Bugreport dokumentiert.
Diese Lösung passt zur Produktstrategie: sinnvolle Unterstützung ohne unnötige Infrastruktur. Sie funktioniert intern mit bekannten Projekten und extern mit den vom Betreiber selbst hinterlegten Zielen.
Qualitätssicherung vor zusätzlichem Funktionsumfang
Die nächsten Schritte konzentrieren sich nicht auf möglichst viele neue Module. Vorrang haben stabile Updatepfade, vollständige Datenhaltung, zuverlässige Modals, saubere Pagination, verständliche Meldungen und Tests mit realistischen Datenbeständen. Auch Dublettenprüfung, Bildähnlichkeit und Historienaktionen müssen in typischen und ungewöhnlichen Fällen kontrolliert werden.
Für die öffentliche Seite bleibt eine klare Anleitung wichtig. Käufer sollen wissen, dass genaue Schritte, technische Angaben und Screenshots die Bearbeitung verbessern. Der Bugtracker soll dabei nicht wie eine technische Dokumentation wirken, sondern verständlich durch die Meldung führen.
Modularer Ausbau mit klaren Grenzen
Spätere Erweiterungen werden daran gemessen, ob sie die Erfassung, Bewertung oder Bearbeitung eines Fehlers verbessern. Ein neues Modul darf den Kern nicht mit fachfremden Funktionen überladen. Die Trennung zwischen bereits umgesetzt, vorbereitet und geplant bleibt sichtbar.
Mit RC22 ist eine belastbare Grundlage erreicht: zentraler Meldeweg, strukturierte Berichte, Produktbezug, Statusmodell, Belohnungen, interne Projektübergabe und eine deutlich robustere Bedienung. Der weitere Weg besteht vor allem darin, diese Bausteine unter realen Bedingungen zu härten und den Bugtracker als fokussiertes WordPress-Produkt verlässlich fertigzustellen.
Release-Reife zeigt sich in wiederholbaren Abläufen
Der nächste Meilenstein ist nicht allein eine neue Versionsnummer. Entscheidend ist, dass zentrale Vorgänge wiederholt und unter verschiedenen Bedingungen zuverlässig funktionieren: Meldung absenden, Produkt bearbeiten, Filter wechseln, Seite zwei öffnen, Anhang aufrufen, Dublette verbinden, Belohnung vergeben und ein Update mit bestehenden Daten durchführen. Jeder dieser Abläufe muss verständliche Rückmeldungen liefern und darf keine stillen Datenverluste verursachen. Erst diese wiederholbare Qualität macht aus einem Release-Candidate ein belastbares Produkt. Die Roadmap bleibt daher bewusst praxisnah und orientiert sich an realen Arbeitswegen statt an einer möglichst langen Funktionsliste.
