In der ILIAS-Community ist Denis Strassner nicht erst seit seinem wohlverdienten Community Award bekannt. Besonders im Test&Assessment engagiert er sich seit vielen Jahren – zunächst als Leiter der SIG E-Assessment, seit Januar 2021 nun auch als Maintainer. Damit trifft Denis die zentralen Entscheidungen für diese Komponente und verantwortet gemeinsam mit dem ILIAS-Produktmanager ihre Weiterentwicklung. 

Ungewöhnlich ist, dass Denis selbst kein Entwickler ist und auch nicht bei einem Service-Provider angestellt ist. Stattdessen arbeitet er als E-Learning-Spezialist im Kommunikations-, Informations- und Medienzentrum (KIM) der Uni Hohenheim. Dort ist er unter anderem das zentrale Bindeglied zur ILIAS-Community.

Neben seinen Aufgaben an der Hochschule widmet er sich ein bis zwei Tage pro Woche dem Test&Assessment (T&A). Nicht selten jedoch kommen etliche Überstunden dazu – denn in der Komponente gibt es immer etwas zu tun.

Wir haben uns mit Denis darüber unterhalten, wie es zu seiner Übernahme der Maintenance kam und wie seine Erfahrungen sind als "non-coding maintainer" von ILIAS.

Hallo Denis! Ein Maintainer, der nicht selber programmiert, ist bei ILIAS eher ungewöhnlich. Wie kam es dazu, dass Du als Nicht-Entwickler die Maintenance einer so wichtigen Komponente wie dem Test&Assessment übernommen hast?

ILIAS wird an der Uni Hohenheim schon lange eingesetzt, unter anderem auch für E-Klausuren. Bereits seit längerem hatte ich mich in der Community für das T&A engagiert. Leider war 2020 der bisherige Maintainer der Komponente aus gesundheitlichen Gründen ausgestiegen. In der Folge war die Weiterentwicklung ins Stocken geraten.

Es gab verschiedene Ansätze, u.a. den Versuch einer schnellen Aufteilung dieser großen Komponente. Doch dieser schnelle Ansatz funktionierte nicht so, wie es ursprünglich geplant war. Im Dezember 2020 standen wir vor dem Dilemma, dass es nicht so vorwärts ging, wie wir uns dies gewünscht hatten – aber die bisherige Codebasis weiter gepflegt und für die Anwenderinnen und Anwender nutzbar gehalten werden musste. In dieser Situation habe ich mich bereiterklärt, die Maintenance zu übernehmen und die zentralen Entscheidungen über den bestehenden Code zu treffen.

Du warst zunächst nur kommissarisch tätig?

Das stimmt. Der damals entwickelte Fragenservice war leider noch nicht dort, wo wir ihn gerne gehabt hätten. Außerdem fehlte noch die Anbindung an Testplayer und Fragenpool. So haben Produktmanager und TB entschieden, dass es sinnvoll ist, das bisherige T&A vorerst unter meiner Maintainerschaft aktiver weiterzuführen.

Mein Ansatz war dabei, den vorhandenen Code in wohlüberlegten Portionen zu verbessern. Ich wollte nicht auf den einen großen – womöglich zu großen – Wurf zielen, sondern lieber Teilbereiche sukzessive verbessern.

Dieser Ansatz wurde von der Community mitgetragen. Inzwischen ist klar, dass wir diesen Weg auch zukünftig gehen werden. Ich bin nun zum dauerhaften Maintainer des T&A geworden – und habe viel Spaß an dieser Aufgabe.

Wie können wir uns Deine Tätigkeit als Maintainer vorstellen? Was sind Deine Aufgaben?

Zu meiner täglichen Arbeit gehören natürlich Konzeptgespräche für Weiterentwicklungen, Verbesserungen und auch Fehlerbehebungen. Diese münden dann oft in Feature-Wiki-Einträge und zugehörige Workshops oder Treffen – und anschließend in Beauftragungen der Entwickler.

Gerade am Anfang habe ich mich viel um offene Tickets in unserem Issue-Tracker Mantis gekümmert, Probleme sortiert und priorisiert. Auch dies gehört zu meinem täglichen Brot.

Ich widme mich auch übergreifenden Themen der ILIAS-Entwicklung. Hierzu gehören aktuell z.B. das Thema Datei-Uploads und die Konfigurierbarkeit der Upload-Größen ebenso wie die nächsten Schritte für die Einführung von Markdown oder UI-Verbesserungen in der CSS Squad.

Darüber hinaus steht auch meine generelle Mitarbeit in der ILIAS-Community oft mit dem T&A in Zusammenhang. Denn die Menschen haben an diese Komponente ganz andere Ansprüche als an kleinere Module. Bei jeder anstehenden Entscheidung gibt es dementsprechend viel Input – und bei unpopulären Entscheidungen natürlich auch Gegenwind.

Wie gehst Du als Maintainer damit um?

Wir befanden uns beim T&A in einem Dilemma: Der Code war zu umfangreich, als dass er noch im erforderlichen Ausmaß hätte gewartet werden können. Für dieses Dilemma suche ich Lösungen – und eine ganze zentrale Lösung ist aus meiner Sicht, die Codemenge zu reduzieren. Dies bedeutet mitunter: Weniger Einstellungen und weniger Funktionen. Es bedeutet aber auch weniger Redundanz von Funktionen. Wer die Komponente gut kennt, entdeckt Bereiche, die recht problemlos abgeschafft werden können, weil die gleiche Funktionalität auch auf anderem Wege erreicht werden kann.

Bei meiner Arbeit versuche ich, den Input der Community stets zu berücksichtigen. Wir kommen jedoch manchmal an den Punkt, wo man mit großen Gremien nicht weiterkommt. Dann hilft meist die Arbeit in kleineren Gruppen, die tiefer in ein Thema einsteigen. In allerletzter Konsequenz muss ich auch mal eine Entscheidung gegen die Community treffen. Denn ich verantworte die Komponente und muss dafür sorgen, dass sie stabil und zukunftssicher ist.

Was machst Du in der Praxis, wenn Du eigene Ideen in den Code bekommen willst – oder als nicht-entwickelnder Maintainer auch bloß einen Bug beheben möchtest?

Was den Code angeht, bin ich auf einen gewissen Good Will der beteiligten Entwickler angewiesen – und auf eine solide finanzielle Basis, um ihre Arbeit beauftragen und bezahlen zu können.

Erfreulicherweise gab es 2022 unter anderem Gelder aus dem Projekt ARKADIEN der Hochschule Bremen, mit denen zentrales Refactoring am Code finanziert werden konnte. Auch der ILIAS-Verein beteiligt sich, insbesondere an den Kosten für das Bugfixing und Refactoring. Dazu kommen weitere Hochschulen und Projekte wie bwILIAS und ILIAS.NRW. Und im Rahmen der Arbeiten an PHP 8 gab es aus der ganzen Community Mittel, um den Code zu verbessern.

Wer implementiert denn den Code? Ist hier vor allem Max Becker von Databay zuständig? Er ist ja der zweite Maintainer des T&A…

Max ist bisher sicher mein Hauptansprechpartner. 90% aller Bugfixes kommen von ihm. Doch seit einiger Zeit arbeiten wir in der sogenannten TechSquad auch in größerer Runde zusammen. Nils Haagen und Richard Klees von CaT, Stephan Kergomard von der Hochschule Luzern, Olivia Kaufmann und Timon Amstutz von der Uni Bern, sowie Pascal Seeland und Ulf Kunze von der Uni Stuttgart sind maßgeblich daran beteiligt. Auch Fred Neumann (FAU) ist, wenn es ihm seine vielfältigen Aufgaben erlauben, mit von der Partie – und schon ein alter Hase im T&A. Wir tauschen uns in dieser Gruppe jede Woche aus, schauen uns die technischen Lösungsideen für Probleme an und diskutieren gemeinsam, welche Ansätze sinnvoll wären.

Für die bessere Organisation der Arbeiten habe ich mehrere Datensammlungen angelegt, in denen ich alle Bugs mit Finanzierungsbedarf oder JourFixe-Entscheidungen sammle. Über die Einträge bitte ich die beteiligten Entwickler um Angebote, behalte den Überblick über den Stand der Arbeiten und unsere finanziellen und zeitlichen Ressourcen.

Dabei geht es ja vor allem um die Finanzierung der Entwickler. Aber wie finanzierst Du Deine eigenen Aufgaben? Du arbeitest ja im Gegensatz zu den meisten anderen ILIAS-Maintainern nicht bei einem Service Provider…

Ich selber verdiene nichts an neuen Features und werde – wie übrigens alle Maintainer – nicht direkt für die Maintenance bezahlt. Aber mein Arbeitgeber unterstützt meine Tätigkeit in der ILIAS-Community, gibt mir die entsprechenden Freiräume und bezahlt mich natürlich auch. Dass die Uni Hohenheim dies macht, freut mich sehr. Es ist ein großer Beitrag zur Weiterentwicklung von ILIAS.

Wie ist der Zustand des T&A heute, nach mehr als 1,5 Jahren unter Deiner Maintenance?

Bei allen Problemen, die wir in der Community diskutieren (und auch nach und nach beheben), dürfen wir nicht vergessen, wie mächtig das T&A ist. Seit vielen Jahren wird diese Komponente an etlichen Hochschulen für zigtausende Prüfungen eingesetzt. Und das nicht ohne Grund: Es gibt meines Wissens kein anderes System, das es erlaubt, so variantenreiche Tests und Klausuren zu schreiben – und gleichzeitig im Code klar sehen zu können, was genau passiert.

Gleichzeitig muss man sagen, dass wir immer noch viel Arbeit vor uns haben. Wir haben eine ganze Menge konzeptioneller Probleme geerbt, an denen wir immer noch knabbern. In Anbetracht der Komplexität des T&A waren in der Vergangenheit einige Angebote zu günstig kalkuliert. Manchmal wurde etwas entwickelt, ohne ein vollständig ausgearbeitetes Konzept zu haben.

An solchen Altlasten arbeiten wir bis heute. So gibt es denn auch weiterhin einen Fokus darauf, die pure Codemenge zu reduzieren. Dass dabei leider auch mal weniger genutzte Features abgeschafft werden, gehört leider dazu.

Wie wird es aus Deiner Sicht weitergehen? Wirst Du uns als Maintainer erhalten bleiben, wo möchtest Du gerne mit dem T&A hin – und wirst Du womöglich selber noch programmieren lernen?

Die Arbeit am T&A macht mir sehr viel Spaß. Ich tauche nun viel tiefer in die Themen ein als früher in meiner Rolle als Admin. Gerne bleibe ich langfristig Maintainer.

Mit meiner Arbeit möchte ich erreichen, dass das Test&Assessment und auch ILIAS ingesamt immer besser wird. Coden lernen steht dabei aber nicht auf der Agenda. Dafür fehlt mir schlicht die Zeit. Die stecke ich dann lieber in die Konzeption des gesamten Systems und der anstehenden Weiterentwicklungen. Denn die Zusammenarbeit mit den Entwicklern klappt ja wunderbar. Einige von ihnen sind sogar froh, mehr entwickeln zu dürfen und weniger konzipieren zu müssen.

Welche Arbeiten stehen konkret an?

Viele Verbesserungen werden zunächst im Hintergrund stattfinden. So ist ein Hauptziel, alle Fragen auf Repository Pattern umzustellen. Dadurch wird der Code besser strukturiert und lesbarer. Probleme können schneller gelöst und Erweiterungen schneller entwickelt werden.

Weiterhin steht auch die Auflösung der starken Verflechtung von Test und Fragenpool auf der Agenda. Dazu müssen wir jedoch zunächst den gesamten Code aufräumen – um ihn anschließend entflechten zu können. Erst in der Folge wird es dann möglich sein, neue Test-Player zu entwickeln.

Auf UI-Ebene wollen wir endlich alte, nicht standardisierte Elemente loswerden. Alle Fragen im Test sollen einen einheitlichen Look bekommen und einen einheitlichen Satz an Funktionen. So sollten z. B. die erreichbaren Punkte immer an der gleichen Stelle eingegeben werden. Diese Standardfunktionen sollten nicht mehr für jeden Fragentyp einzeln, sondern an einer Stelle gemeinsam entwickelt werden.

Aufgrund der Knappheit an Entwicklerressourcen werden diese umfangreichen Arbeiten sicher noch eine Weile brauchen. Ich kümmere mich darum, sie in kleinere Portionen aufzuteilen. Erst nach Abschluss dieser tieferen Arbeiten werden wir "oben" auf der Benutzerseite wieder größere neue Features hinzufügen.

Bereits jetzt werden aber sichtbare Verbesserungen an der UI umgesetzt. So erhalten wir eine bessere Lesbarkeit, höhere Einheitlichkeit, elegantere Anpassungen für große und kleine Bildschirme, und vieles mehr. Ferdinand Engländer von CaT hat hier schon viel bewegt.

Abschließend würde mich interessieren, ob diese Art der Maintenance auch für andere Komponenten geeignet sein könnte?

Sie könnte sicher ein Modell sein für Komponenten, die Endanwenderinnen regelmäßig sehen und nutzen. Sicherlich müsste diese Komponente auch eine besondere Wichtigkeit für die Community haben, damit Entwickler bereit sind, Ressourcen für ihre Weiterentwicklung aufzuwenden.

Die Zusammenarbeit mit mehreren Entwicklern gibt es ja auch in anderen Komponenten. Sie hat sich aus meiner Sicht bewährt. Es wäre dann durchaus vorstellbar, dass gute Projektmanager bei ILIAS-Service-Providern Maintainer werden, ohne selber zu entwickeln. Wenn die Entwickler bereit sind, die Koordinierung der Maintenance und die Konzeption neuer Features abzugeben, könnte ein solches Modell auch anderswo funktionieren.

Denis, vielen Dank für diesen Einblick in Deine Arbeit – und danke Dir und allen Maintainern für Ihren Einsatz für ILIAS!