Wikonia:Work-Tools (Projekt)/Evaluierung Requestmanagement
1. Zielsetzung[Bearbeiten | Quelltext bearbeiten]
Implementierung eines Systems für Bugtracking, Requestmanagement und technische Weiterentwicklung, das unabhängig von MediaWiki betrieben werden kann und flexible Workflows unterstützt.
Im Mittelpunkt stand ein möglichst tech-orientiertes, zugängliches Requestsystem – keine agile Projektmanagement-Spielwiese.
2. Evaluierte Optionen[Bearbeiten | Quelltext bearbeiten]
A) Taiga
- Vorteile:
- Grundsätzlich viele moderne Funktionen, Self-Hosting möglich
- Nachteile:
- Oberfläche wenig modern, auf mobilen Geräten praktisch unbrauchbar
- Responsivität auf dem Niveau von Stahlbeton
- Community-Edition extrem funktionsreduziert, viele essenzielle Features nur in SaaS oder Enterprise
- Django-Admin-Basis umständlich und altbacken
- Ergebnis:
- Kurzzeitig eingeführt, aber im Alltag (insbesondere für technische Anforderungen) unbrauchbar und wieder entfernt
B) Phabricator
- Vorteile:
- Historisch bewährte Plattform (u. a. Wikimedia nutzt(e) sie)
- Viele Features für große Open-Source-Projekte
- Nachteile:
- Entwicklung faktisch eingestellt („stale“)
- Praktisch keine gepflegten Repositories mehr
- Kaum noch Support, Integrationen veralten
- Ergebnis:
- Ursprünglich Wunschlösung, wurde aber wegen fehlender Weiterentwicklung ausgeschlossen
C) Phorge
- Vorteile:
- Aktive Community, Fork von Phabricator
- Erfüllt alle Feature-Anforderungen für Tech-Requestmanagement
- Umfangreiche API/Webhook-Integration, automatisierbar
- Nach Aufwand für eigenes Docker-Setup jetzt stabil und updatefähig im Einsatz
- Nachteile:
- Aufwändige Erstinstallation, Docker-Image musste selbst gebaut werden
- UI nicht sonderlich modern, aber funktional
- Ergebnis:
- Nach erheblichem Setup-Aufwand ist Phorge jetzt klar bevorzugt und deckt alle Anforderungen ab
D) Redmine
- Vorteile:
- Verbreitet, viele Erweiterungen
- Lauffähig im Docker, Open Source
- Nachteile:
- Oberfläche und UX wenig überzeugend, Workflow nicht flexibel genug
- Konnte Workflows/Tickets und Projekte nicht ausreichend differenzieren
- Kein Fokus auf Tech-Requestmanagement
- Ergebnis:
- Nur kurz getestet, dann aussortiert
E) MantisBT
- Vorteile:
- Schnell lauffähig, moderne (klickibunti) Oberfläche
- Nachteile:
- Für „normale Nutzer“ abschreckend, wirkt überladen
- Einstieg zu kompliziert, zu sehr in Richtung agiles Board
- Ergebnis:
- Kurz getestet, aber für Nutzerakzeptanz zu „wuchtig“, daher ausgeschlossen
F) GitHub Issues
- Vorteile:
- Integration mit GitHub-Repo/Commits
- Vertrautheit im Entwicklerumfeld
- Nachteile:
- Für Nicht-Devs und Gelegenheitsnutzer unzumutbar
- Bedienung über Markdown/Labels wenig intuitiv
- Kaum Übersicht bei vielen Tickets, keine Workflows
- Ergebnis:
- Vorübergehend genutzt, dann wieder entfernt
G) Jira
- Vorteile:
- Umfangreich, Standard im Unternehmensbereich
- Nachteile:
- Datenschutz und Kosten problematisch
- Oberfläche „klickibunti“, für kleine Projekte zu aufgeblasen
- Schnittstellen- und Erweiterungszwang (nur Atlassian Store, Veröffentlichungspflicht, jede Iteration muss genehmigt werden)
- Eigenentwicklung und Anpassung praktisch nicht möglich – widerspricht der Projektphilosophie
- Ergebnis:
- Aus Datenschutz-, Kosten- und Flexibilitätsgründen sofort verworfen
H) Trello
- Vorteile:
- Intuitive Boards
- Nachteile:
- Nicht FOSS, keine Integrationsmöglichkeiten
- Kein Tech-Fokus, kein sauberes Bug-/Featuretracking
- Ergebnis:
- Kurze Erwägung, direkt verworfen
3. Entscheidung und Begründung[Bearbeiten | Quelltext bearbeiten]
Phorge wurde nach ausführlicher Evaluierung, teils erheblichem technischem Aufwand und diversen Tests als einziges Tool gefunden, das alle Ansprüche an Tech-Request- und Bugmanagement erfüllt, stabil im eigenen Docker-Setup läuft und nicht auf agile Methodik oder schwerfällige Workflows angewiesen ist.
Taiga, MantisBT, Redmine und GitHub Issues scheiterten entweder an Akzeptanz, Usability oder fehlenden Features. Jira und Trello widersprachen mit ihrem Setup und Modell grundsätzlich der Projektphilosophie.
Fokus: Eigenständigkeit, Automatisierbarkeit, technische Transparenz und keine unnötigen Hürden für Gelegenheitsnutzer.