Wikonia:Work-Tools (Projekt)

Projektbeschreibung

Ziel dieses Projektes ist die strategische Auswahl externer Software-Tools ("Work-Tools"), die für den reibungslosen Betrieb und die Organisation von Wikonia unerlässlich sind. Wir konzentrieren uns hier ausschließlich auf eigenständige Anwendungen, die unabhängig von unserer MediaWiki-Instanz operieren.

Nicht Gegenstand dieser Dokumentation sind:

• Komponenten, die direkt mit MediaWiki, seinen Erweiterungen (Extensions), Lua-Modulen oder Gadgets verbunden sind.
• Interne Entwicklungen wie Bots und Skripte.
• Klassische Infrastrukturthemen wie Hosting, Backup oder Dateispeicherung.

Unser Fokus liegt auf jener Software, die den digitalen "Maschinenraum" von Wikonia bildet – Tools für Kommunikation, Organisation, Weiterentwicklung und Monitoring.

Ziel dieser Dokumentation ist es, eine transparente und zentrale Übersicht über alle evaluierten und eingesetzten Tools zu schaffen. Dies gewährleistet die Nachvollziehbarkeit unserer Entscheidungen, vermeidet Redundanzen und ermöglicht eine koordinierte Weiterentwicklung im Team. Jede Software wurde einem rigorosen Auswahlverfahren unterzogen, dessen Kriterien und Ergebnisse hier detailliert dargestellt werden.

Bedarfsanalyse

Für den Betrieb und die Organisation von Wikonia ergeben sich folgende funktionale Anforderungen an externe Softwarelösungen:

E-Mail:

Es besteht ein Bedarf an zentraler E-Mail-Kommunikation. Dies umfasst den Versand und Empfang projektbezogener Nachrichten, die Verwaltung offizieller E-Mail-Adressen sowie die Möglichkeit, sich nach außen als offizieller Absender der Plattform auszuweisen.

Kommunikationsmanagement / Kontaktmanagement:

Für externe Anfragen (z. B. Beschwerden, Kooperationsanfragen oder Korrekturwünsche) ist ein System erforderlich, das eine strukturierte Erfassung, Nachverfolgung und Kategorisierung ermöglicht. Eine zeitnahe und nachvollziehbare Bearbeitung der Vorgänge muss sichergestellt sein. Darüber hinaus wird Wert auf die Standardisierung von Antworten gelegt, beispielsweise durch den Einsatz von Vorlagen oder Textbausteinen.

Code-/Requestmanagement:

Zur Verwaltung technischer Aufgaben, Funktionswünsche und Fehlerberichte wird eine Plattform benötigt, die Transparenz im Entwicklungsprozess, die Priorisierung von Aufgaben und die Dokumentation von Änderungen und Diskussionen ermöglicht.

Monitoring & Logging:

Für den laufenden Betrieb ist die Überwachung der Systemverfügbarkeit und die Protokollierung relevanter Ereignisse erforderlich. Ziel ist die frühzeitige Erkennung von Ausfällen oder Problemen sowie die nachvollziehbare Dokumentation aller Systemereignisse.

Chat/Messaging (Teamkommunikation):

Eine Lösung für den schnellen, informellen Austausch im Team (z. B. zu laufenden Themen oder zur spontanen Abstimmung) wurde geprüft. Aktuell wird jedoch auf ein solches System verzichtet, da kein akuter Bedarf besteht.

Auswahlprozess

E-Mail

Für die E-Mail-Kommunikation wurde besonderer Wert auf ein wartungsarmes und stabiles System gelegt. Klassische Setups mit Einzelkomponenten wie Dovecot und Postfix wurden aufgrund des hohen Wartungsaufwands und möglicher Risiken für die Kernfunktion des Servers ausgeschlossen. Externe Anbieter wurden aus Datenschutz- und Integrationsgründen verworfen. Aktuell kommt eine eigenständig betriebene Mailcow-Instanz zum Einsatz.

→ Siehe: Detaillierte Darstellung Auswahlprozess

Kommunikationsmanagement / Kontaktmanagement

Zur strukturierten Bearbeitung und Nachverfolgung externer Anfragen wurden verschiedene Systeme geprüft. osTicket wurde zunächst als Hauptlösung in Betracht gezogen. Aktuell wird Zammad favorisiert und getestet. SaaS-Angebote ohne eigene Infrastruktur sowie eine rein manuelle E-Mail-Bearbeitung wurden aus Gründen der Transparenz, Nachvollziehbarkeit und des Datenschutzes verworfen. Sollte sich Zammad als ungeeignet erweisen, wird osTicket alternativ eingesetzt.

→ Siehe: Detaillierte Darstellung Auswahlprozess

Code-/Requestmanagement

Für das Aufgaben- und Entwicklungsmanagement wurde zunächst Taiga zur Vorplanung eingesetzt, wird aber wieder abgeschafft. GitHub Issues wurde temporär genutzt, ist jedoch ebenfalls nicht mehr im Einsatz. Jira und Trello wurden aus Gründen der Komplexität beziehungsweise mangelnder FOSS-Strategie ausgeschlossen. Für künftige Anforderungen ist Phorge als Plattform für Coding und Requestmanagement vorgesehen.

→ Siehe: Detaillierte Darstellung Auswahlprozess

Monitoring & Logging

Im Bereich Systemüberwachung und Protokollierung wurden verschiedene Open-Source-Lösungen wie Grafana, Prometheus und Netdata betrachtet. Klassische Enterprise-Lösungen und komplexe Setups wurden als für den aktuellen Anwendungsfall überdimensioniert und zu wartungsintensiv bewertet. Eine einfache, wartungsarme Lösung wird angestrebt, eine endgültige Auswahl steht noch aus.

→ Siehe: Detaillierte Darstellung Auswahlprozess

Chat/Messaging (Teamkommunikation)

Für den informellen und schnellen Austausch wurden Lösungen wie Slack, Rocket.Chat, Matrix, Mattermost und Zulip evaluiert. Aufgrund des Aufwand-Nutzen-Verhältnisses und der fehlenden Dringlichkeit im aktuellen Teamkontext wurde bisher kein System eingeführt. Das Thema bleibt perspektivisch offen, ist derzeit jedoch nicht relevant.

→ Siehe: Detaillierte Darstellung Auswahlprozess

Ergebnisse

Die wichtigsten externen Tools für den Betrieb und die Organisation von Wikonia wurden in einem transparenten Auswahlverfahren bewertet. Die beiden priorisierten Werkzeuge – das E-Mail-System und das technische Request-/Bugmanagement – wurden final ausgewählt und sind produktiv im Einsatz.

Entscheidungen über weitere Tools (z. B. Monitoring/Statusübersicht) werden bei Bedarf und wachsendem Anwendungsfall nachgezogen. Für Bereiche wie Chat/Messaging hat die Evaluierung ergeben, dass der Aufwand zur Implementierung in keinem Verhältnis zum Nutzen steht; eine Umsetzung ist auch mittelfristig nicht vorgesehen.

Sachstand (tabellarische Übersicht)

Bedarf	Tool/Lösung	Status	Kommentar
E-Mail	Mailcow	Produktiv	Wartungsarme Komplettlösung, aktiv im Einsatz
Kontaktmanagement	Zammad*/osTicket	Auswahl getroffen	Testbetrieb läuft, endgültige Entscheidung folgt ggf.
Code/Requestmanagement	Phorge	Produktiv	Docker-Setup im Einsatz, stabile Workflow-Basis
Monitoring/Logging	Netdata*	Auswahl offen	Pragmatische Lösung, eigenentwickelte Statusseite denkbar
Chat/Messaging	—	Nicht umgesetzt	Aufwand/Nutzen zu ungünstig, Thema abgeschlossen

*Tool im Test- oder Auswahlprozess, noch nicht endgültig produktiv.

Abschluss

1. Mit der Umsetzung der Kernfunktionen ist das Projekt für den aktuellen Bedarf abgeschlossen.
2. Weitere Tools werden nachgezogen, sobald sie betrieblich notwendig oder sinnvoll erscheinen.
3. Alle Entscheidungswege sind auf den jeweiligen Unterseiten dokumentiert und können bei Bedarf fortgeschrieben werden.