Wissensspeicher, Projektmodell, Organisationstalent oder Schwarzes Loch - GitLab als Management-Tool für DH-Projekte

Management Tools in den DH

"Just as Git has influenced the way I approach digital critical editions, the nature of critical editions has influenced the way I think about Git." (Huskey 2023, 11)

Interdisziplinarität in DH-Projekten manifestiert sich häufig in einem großen Team an Mitarbeitenden, nicht selten räumlich verteilt, in jedem Fall aber digital arbeitend, die mit ganz unterschiedlichen Vorstellungen und einer großen Bandbreite an Perspektiven, Denkweisen und "working cultures" aufeinandertreffen (vgl. Edmond 2016). Hier bedarf es einer Vermittlerrolle, die das Projektmanagement übernimmt. Diese Aufgabe fällt häufig der DH-Seite zu, begründet in der dort vorhandenen Doppelqualifikation aus technischer und geisteswissenschaftlicher (Aus-)bildung. Dennoch wird das Thema Projektmanagement in den DH-Curricula kaum abgedeckt: "Bei allen Lehrangeboten ist auffällig, dass ein Fokus auf die Projektplanung und nicht auf das Management einer laufenden Zusammenarbeit gelegt wird. Planungskompetenz ist vorhanden, und vor allem Fähigkeit zur Selbstorganisation, aber eine Moderationskompetenz sowie Fähigkeiten, Techniken und Methoden zur Organisation einer Zusammenarbeit fehlen." (Cremer 2019)

Behelfsmäßig wird dann gerne auf Verfahren und Werkzeuge aus der Software-Entwicklung zurückgegriffen und diese mehr oder weniger erfolgreich adaptiert (vgl. Chan et al. 2017). So hat sich im DH-Bereich der Einsatz von aus der Softwareentwicklung stammenden Werkzeugen und Plattformen bewährt, die auf sogenannter Versionsverwaltung basieren.¹  Git und Anwendungen wie GitHub und GitLab versprechen Transparenz, Reproduzierbarkeit und Nachhaltigkeit²  (vgl. Nüst 2018; Broyles 2020) und werden in vielen DH-Projekten genutzt (vgl. Huskey 2023, 10).³  Auch das Versprechen von (und die Forderung nach) Open Source (vgl. Jannidis 2017, 94) und Open Science bzw. Crowdsourcing (vgl. Schöch 2017, 208) scheint damit eingelöst werden zu können.

Literatur und Studien, die den Umgang mit diesen Tools und die Auswirkungen auf die Anwender*innen und den Anwendungskontext betrachten, gibt es kaum.⁴  Ansätze wie die auf der DH2016 vorgestellte Studie (Spiro 2016a) zur Evaluierung der GitHub-Nutzung in den DH scheinen weiterführende Untersuchungen nicht inspiriert zu haben.⁵  Einer der neuesten Beiträge (Huskey 2023) beschäftigt sich speziell mit der Nutzung der git commit history als Forschungstagebuch. Auf die veränderten Gewichtungen und Rollenverteilungen im Projekt-Ökosystem⁶  und mögliche Konsequenzen geht der Autor jedoch nicht ein.

Am Beispiel eines bereits seit 2015 laufenden DH-Projekts stellen wir die Frage, wie sich die Nutzung von git und die geisteswissenschaftliche Arbeit gegenseitig beeinflussen. Denn festzuhalten ist: (fast) jede*r kennt, erwartet und verwendet git, kaum jemand ist sich aber über Potential, Grenzen und Probleme im Klaren.

Erfahrungen aus dem Luhmann-Projekt

Das Akademievorhaben "Niklas Luhmann – Theorie als Passion" (2015-2030)⁷  hat die Digitalisierung und Erschließung des wissenschaftlichen Nachlasses des Soziologen Niklas Luhmann zum Ziel. Projekt-Datenmanagement und -Kommunikation erfolgen dabei über eine von der Universitätsbibliothek Bielefeld gehostete GitLab-Instanz.

Der intensive Einsatz der Plattform lässt sich an einigen Zahlen ablesen: Die unter dem Luhmann-Projekt versammelten 57 Repositories haben eine Größe von insgesamt 5,5 GB und umfassen ca. 5.600 issues (2.500 davon "offen", d.h. in Bearbeitung). Die Bandbreite an Dateiformaten umfasst u.a. (TEI-)XML, XSLT, XQuery, XProc, JS, Python, HTML, CSS, MD, Tabellen und Textdokumente sowie Binärformate für Bilddateien (JPG, SVG, Tiff) und Audio (mp3, wav). Gespeichert werden die Objekte in Form von TEI-XML-Dateien selbst sowie Modelle und Skripte zur Qualitätssicherung, außerdem Skripte für die interne Editionsumgebung und für das Back- und Frontend der Digitalen Edition. Hinzu kommen Worddateien, Excelllisten, Bilder u.ä. zur internen Dokumentation. Derzeit sind 21 Mitarbeitende als project member verzeichnet. Die Zahl der pro Tag erfolgten commits ist schwer zu beziffern und für jedes Repository unterschiedlich, es dürfte sich in den Kern-Repositories um eine Zahl im mittleren zweistelligen Bereich handeln.⁸ 

Neben der Funktion als Datenspeicher wird GitLab von Beginn an als primäres Tool zur Kommunikation, Dokumentation und Aufgabenverteilung genutzt. Systematische Dokumentation geschieht über Markdown und git pages . Der Austausch darüber, was im Projekt zu besprechen, entscheiden oder erledigen ist, wird über issues geführt. Die Inhalte reichen von Fehlermeldungen über Modellfragen bis hin zu fachwissenschaftlich-editorischen Detaildiskussionen. Durch den nicht verpflichtenden Einsatz von labeln kann eine Kategorisierung der issues vorgenommen werden. Todos werden in unterschiedlichen Granularitätsstufen festgelegt (spezifische wie "Button xy in der Anzeige um 10px nach rechts verschieben" oder allgemeine wie "alle Literaturverweise im edierten Text auszeichnen"). Durch assignments ist jedes issue einer verantwortlichen Person zugewiesen. Das mentioning von Personen stellt eine Möglichkeit dar, Mitarbeitende auf einen Sachverhalt aufmerksam zu machen, ohne dass akuter Handlungsbedarf besteht.

Fazit

Wir haben eingangs die Frage gestellt, wie ein Werkzeug, das auf Produktion und Softwareentwicklung ausgerichtet ist, den Umgang der Projektbeteiligten miteinander und mit dem eigenen Arbeiten beeinflusst. Unsere Beobachtungen zeigen, dass es eine DH-spezifische Nutzung von git gibt. Macht erst – und gerade – diese nicht intendierte geisteswissenschaftliche Nutzung aus Plattformen wie GitLab ein – adäquates – Projektmanagement-Tool? Eine GitLab-Instanz kann ein Forschungstagebuch darstellen und als solches bedeutende Einblicke in die Entwicklung und Theoriebildung von Projekten bieten, deren Veröffentlichung die Forschung nachhaltig bereichern würde. Diese Anwendung erfordert jedoch sorgfältige Planung, konstante Pflege und kommt nicht völlig ohne Regeln aus. Um allgemeingültige Empfehlungen für die DH-Community entwickeln und Best Practices etablieren zu können, bedarf es allerdings weiterer Erfahrungsberichte aus der DH-Praxis, die zeigen, wie Werkzeuge dieser Art mit Erfolg eingesetzt werden.

¹ Zur Eignung speziell von GitHub und Versionierungsverwaltung als Digital Library s. die Studie von Minkova (2018).

² Git ( https://git-scm.com/ ), GitHub ( https://github.com/ ), GitLab ( https://gitlab.com/ ).

³ Dazu beitragen dürfte der Umstand, dass git gerade Text-basierte Dateiformate besonders gut verarbeiten kann. Vgl.Huskey 2023, 19, und Spiro & Smith 2016, Folie 20.

⁴ Eine etwas ältere Übersicht (Stand 2019) bietet F. Cremer in seinem Blogpost (Cremer 2019), in der er die im deutschsprachigen kaum existente und im englischsprachigen Raum vorwiegend auf Projektplanung ausgerichtete Literatur beklagt. Das gerade erschienene Werk von Cremer et al. 2024 beschäftigt sich ausführlicher mit scrum, einem Modell für das agile Projektmanagement, geht jedoch auch nicht weiter auf die kollaborative Arbeit mit git ein.

⁵ Die Ergebnisse dieser speziell auf GitHub ausgerichteten Studie umfassten Bedenken bez. Geschäftsmodell und Langzeitsicherung der Daten einerseits, die hohe Einstiegshürde beim Erlernen von git sowie die relative Ungeeignetheit für nicht-textliche Daten andererseits. Vgl. dazu auch Spiro & Smith 2016 und den Blogartikel Spiro 2016b.

⁶ Zur Rollenverteilung in kollaborativen DH-Projekten s. auch Gardiner & Musto 2015, 43-66. Komprecht und Röwenstrunk (2016, 519) weisen auf die Hürden bei der Festlegung von Zuständigkeiten und die Bedeutung einer “offene[n] und kollegiale[n] Informationspolitik” hin.

⁷ Siehe das laufende Portal "Niklas Luhmann-Archiv" unter https://niklas-luhmann-archiv.de/ .

⁸ Als Bsp. für ein derzeit stark in Bearbeitung befindliches Repository ("manuskripte") ergibt eine git log-Abfrage (für den Zeitraum 11. und 12.07.24) 42 commits von insgesamt 4 bearbeitenden Personen.

⁹ Projektwebseite, Download und Dokumentation unter https://github.com/apps/desktop .

¹⁰ Vgl. dazu "But that in itself does not solve the problem of haphazard record-keeping. In the absence of any project guidelines for using Git, contributors can make as few or as many commits as they please. And since there are few rules about the content of a commit message, it is possible, and unfortunately common, for contributors to do the bare minimum by writing generic messages (e.g., "Adding some files" or "Fixed a bug") without any further documentation, greatly reducing the usefulness of a project’s log [...]." Huskey 2023, 14.