Seit dem Frühjahr gibt es bei ILIAS nun eine reguläre „Contributor“-Rolle (wir berichteten). Diese Rolle bietet ein geregeltes Verfahren für Beiträge von Nicht-Maintainern zum Programmcode. Interessierten können nun ganz einfach Fehler  beheben oder vorhandenen Code verbessern. Dazu setzen sie die erforderlichen Änderungen direkt um und schicken diese als Vorschlag (sogenannter „Pull Request“) an den zuständigen Maintainer. Segnet dieser die Änderungen ab, kann er sie ganz einfach in die offizielle ILIAS-Version übernehmen.

Wir haben uns mit Fabian Schmid vom Technical Board darüber unterhalten, wie die neue Rolle angenommen wird und welche weiteren Möglichkeiten das Board sieht, die Maintainerschaften besser zu verteilen.
 

Wie sind die Erfahrungen mit dem Code Contributor auf GitHub, mit der nun auch externe Entwickler ganz leicht Verbesserungen und Fehlerbehebungen zu ILIAS beisteuern können?

Bisher haben wir sehr gute Erfahrungen gemacht. Die Code-Beiträge über Pull Requests haben stark zugenommen. Wir haben mittlerweile über 800 Requests erhalten. Diese kommen oft von anderen Maintainern, aber auch aus bisher unbekannten Ecken. Unternehmen außerhalb der bekannten ILIAS-Szene beteiligen sich, da sie ILIAS vielleicht selber oder für ihre Kunden nutzen. Das tolle daran ist, dass die Maintainer entlastet werden: Wenn ein anderer Entwickler einen Bug findet und in Mantis meldet, liefert er nun oft einen Pull Request zur Behebung des Fehlers mit.

Die Contributor-Rolle trägt also zur Kooperation zwischen den Maintainern bei…

…und öffnet die Entwicklung nach außen. Es ist jetzt endlich eine Zusammenarbeit auf Augenhöhe mit Entwicklern möglich, die nicht zum Kernteam gehören. Diese können neben Fehlerbehebungen auch andere Verbesserungen einbringen - also zum Beispiel Code überarbeiten, damit er eleganter oder schneller wird. Auch Code-Dokumentation kann beigesteuert werden. Lediglich neue Features müssen nach wie vor durch den Jour Fixe.

Hat das neue Verfahren auch Nachteile?

Manchmal werden sehr große Änderungen vorgeschlagen oder die weiteren Auswirkungen eines Änderungsvorschlags sind nicht gleich klar. Dies erfordert dann Testing und eine tiefere Analyse durch den Maintainer, bevor der Request übernommen werden kann. Laut der Regel sollen Pull Requests innerhalb von 21 Tagen vom Maintainer beantwortet werden. Wird der Aufwand zu groß, stoßen wir bei umfangreichen Pull Requests an unsere Grenzen. Dann besteht nur die Möglichkeit, den Request abzulehnen - oder ihn länger als 21 Tage liegen zu lassen.

Wie geht das Technical Board damit um?

Wir führen seit einiger Zeit Buch darüber, welche Pull Requests besonders lange liegen bleiben. Wir fragen dann direkt beim Maintainer oder auch beim Contributor nach, wo das Problem liegt. Manchmal hilft es schon, wenn der Contributor ein paar Informationen nachliefert oder seinen Vorschlag auf mehrere kleinere Requests aufteilt. So wollen wir verhindern, dass Pull Requests zu lange liegen bleiben. Insgesamt ist die Qualität der Vorschläge und die Bearbeitungszeit aber zufriedenstellend!

Das Technical Board hat sich ja über die Contributor-Rolle hinaus vorgenommen, neue Maintainerschaftsmodelle zu finden. Wie ist hier der Stand der Dinge?

Die Überarbeitung des Maintenance-Modells ist das bislang schwierigste Thema, das vom Technical Board aufgegriffen wurde: Was sind sinnvolle Ansätze? Wie schaffen wir es, noch mehr Maintainer an Bord zu holen? Und wie gestalten wir die Zusammenarbeit praktikabel? Zwei Dinge können hierbei helfen: Vermehrte automatisierte Tests und bessere Dokumentation im Code.

Automatisiertes Testing über Unit Tests erleichtert es den Maintainern, die Beiträge anderer besser einschätzen zu können. Mit Hilfe dieser Tests kann schnell geprüft werden, ob Änderungen womöglich zu neuen Problemen führen. Tests können es auch erleichtern, Verantwortlichkeiten für Bugs zu klären. Aus diesem Grund haben wir auch zum Thema Unit Tests eine Ausschreibung veröffentlicht.

Gibt es Bereiche, in denen solche Tests bereits Erfolge gebracht haben?

Im UI Service (vulgo: „Kitchen Sink“) hat sich der Ansatz bewährt. Dort gibt es eine relativ hohe Testabdeckung. Gleichzeitig arbeiten sehr viele Entwickler daran mit: Jede UI-Komponente kann von einem eigenen Entwickler entwickelt werden. Timon Amstutz und Richard Klees koordinieren das ganze und klären ggf. auch, wer welchen Bug beheben muss.

So ein Modell könnte auch bei anderen Services angewendet werden. Wir stehen hier allerdings noch am Anfang - da die meisten Komponenten eben nicht so leicht in eine Struktur dieser Art überführt werden können. Die Ausschreibung zur Aufteilung von Kurs und Test wird hier hoffentlich neue Ideen bringen.

Du hast auch die bessere Dokumentation erwähnt. Diese wird natürlich dann wichtiger, wenn viele Leute an der gleichen Baustelle arbeiten…

Zur gemeinsamen Nutzung von Services werden Schnittstellen (sogenannte „interne Interfaces“) benötigt. Diese regeln jeweils ganz genau, welchen Teil eines Services andere Entwicklerinnen benutzen dürfen und welchen nicht. So ist für alle klar, auf welche Funktionen man sich verlassen kann und auf welche nicht. Änderungen an diesen Interfaces müssen anschließend durch den Jour Fixe. Bei vielen „alten“ Komponenten sind diese Schnittstellen nicht klar definiert - so dass andere Entwickler nicht mit Sicherheit darauf zugreifen können.

Wir möchten daher auch für bestehende Komponenten solche Schnittstellen definieren. Hier wird die Dokumentation bedeutsam. Denn die Schnittstellen müssen nicht unbedingt auf einer strikt technischen Ebene angelegt werden, sondern zum Teil schlicht als Dokumentation. So wird dann in einer Datei erklärt, welcher Teil eines Services auf welche Weise genutzt werden kann und welche Teile ggf. verändert werden.

Nun ist die Dokumentation aber immer auch aufwändig. Was muss geschehen, damit wirklich alle Entwicklerinnen und Entwickler hier an einem Strang ziehen?

Du hast Recht: Dokumentation bedeutet Mehraufwand - zumindest kurzfristig. Denn langfristig zahlt sich gut dokumentierter Code immer aus. Wie dieser Mehraufwand im einzelnen bewältigt wird, muss jeder Entwickler bzw. jeder Dienstleister selbst entscheiden. Es ist denkbar, den Aufwand direkt in den Angeboten zu berücksichtigen. Man kann die Dokumentation natürlich nicht überall kostenlos nachreichen, aber bei Neuentwicklungen sollte sie gleich beachtet werden. Dies gilt zum Beispiel auch für die geplante Aufteilung von Kurs und Test. Denn nur mit der richtigen Doku werden die Komponenten für alle Entwicklerinnen und Entwickler transparent - nicht nur für die Maintainer.

Fabian, vielen Dank für Deine Zeit und weiterhin gute Arbeit im Technical Board!