Mit einem lachenden und einem weinenden Auge haben wir uns die vielen großartigen Ideen beim HFD-Hackathon angesehen. Vor allem acht der 76 vorgestellten Projekte planen, Orientierungsangebote zu entwickeln, die die zunehmend unübersichtliche Anzahl an Beratungsangeboten oder digitalen Tools und Lernangeboten zielgruppenspezifisch strukturieren und Nutzer_innen auf ein passendes Angebot hin- oder direkt verweisen.

So fokussiert die Toolbox eine Orientierung hinsichtlich vorhandener Tools in der digitalen Bildung anhand bestimmter Kategorien. Sie soll kollaborativ weiterentwickelbar sein. Die Plattform zu Rassismus an Hochschulen soll das aktuell nicht ausreichende Angebote an Antidiskriminierungsberatung ergänzen und einen Raum zum Austausch von Menschen bieten, die von Diskriminierung betroffen sind bzw. unterstützen wollen. Das Digital Education Dashboard (DigEDa) soll einen Überblick über Tools der digitalen Lehre geben – jedoch nach Institutionen filterbar – und zudem konkrete Empfehlungen geben. Darüber hinaus sollen Lehrende (persönlichen) Support bei technischen Problemen erhalten. Die Plattform „Chancengleichheit für alle Studierende-StudEqual“ soll barrierefreie Lerninhalte und Unterstützungsangebote bereitstellen. Der Beratungslotse „Follow me“ soll Studierenden helfen, ihren Weg durch den “Beratungsdschungel“ an einer Hochschule ausgehend von einem Entscheidungsbaum zur richtigen Anlaufstelle bzw. Person für ihr Anliegen zu finden. Das Toolcast: digitale Tools in Lehrerbildung und Schule strebt eine expert_innenbasierte Erprobung und Auswahl verschiedener Werkzeuge und Plattformen sowie der Ergebnisdarstellung an. Der RecoMentor – Lern- und Information Recommender ist ein KI-Empfehlungssystem für Lerninhalte. Survey² – Research goes on(line): Community für Onlineforschung will eine Plattform entwickeln, auf der Forschenden sowie Studierenden u.a. passende Tools empfohlen werden.

Diese Projektideen zeigen, dass ein hoher Bedarf, nicht nur an konkreten Tools und Angeboten, sondern auch der zielgruppen- und themenspezifischen Orientierung vorhanden ist.

Die Art, sich elektronisch zu vernetzen und zu kommunizieren, hat sich in den vergangenen Jahren stark verändert. Soziale Netzwerke sind an die Stelle von Email getreten und Smartphones zu den zentralen Eingabegeräten geworden. Die Kommunikation in diesen Netzwerken verzichtet auf Schnörkel und kann binnen Kurzem viele Akteur_innen einbinden. Insbesondere in der aktuellen Zeit, in der die meisten Personen im Homeoffice arbeiten, gewinnen niederschwellige, zum Teil auch informelle Kommunikationswege an Bedeutung. Aber auch in entspannteren Zeiten haben soziale Netzwerktools in Lehre und Forschung schon ihren Platz eingenommen (vgl. Perkel, 2016 und Hand, 2016a, 2016b).

Am Institut für Technische Bildung und Hochschuldidaktik (ITBH) haben wir 2016 Mattermost eingeführt, um das Potenzial eines modernen Chattools zu testen. Slack schied nicht zuletzt aufgrund seines Geschäftsmodells und seiner Datenschutzbedingungen aus. Mattermost ist freie Software und damit auch mit der Policy für Offenheit in Forschung und Lehre der TUHH vereinbar. Waren anfangs nur wenige Kolleg_innen aktiv, wächst deren Zahl mit jedem neuen Projekt an. Die Akzeptanz von Mattermost als zentralem Kommunikationswerkzeug gelang vor allem mit einer persönlichen Einführung in die Anwendung des Tools und einem gemeinsamen Aushandlungsprozess, wie es allen Beteiligten den größten Nutzen bringt – und mit Geduld. Da es direkt mit der GitLab-Instanz der TUHH verbunden ist, ergeben sich weitere positive Effekte in der Projektkoordination.

Projektkommunikation im Team

Die oberste technische Ordnungseinheit ist in Mattermost das Team. Ob Teams nach außen sichtbar und frei zugänglich sind, kann individuell entschieden werden. Es macht Sinn, die Teilnahme an einem Team über Einladungen zu steuern, da bei aller gewünschten Transparenz oft Interna verhandelt werden. An der TUHH sind mittlerweile mehrere Institute in Mattermost-Teams organisiert und beziehen auch externe Partner_innen bspw. in Drittmittelprojekten mit ein.

Für den Austasch zur digital gestützten Lehre an der TUHH wurde im März 2020 das hochschulweite Team OnlineEduTUHH eingerichtet. Eine Einleitung zur Anmeldung für dieses Team gibt es in den Praktischen Tipps für das Umstellen der Präsenzlehre an der TU Hamburg.

Transparent kommunizieren

Mattermost kennt drei Abstufungen von Transparenz im Team:

• Öffentliche Kanäle. Öffentliche Kanäle können von allen Teammitgliedern angelegt und abonniert werden. Die Kommunikation in einem öffentlichen Kanal kann von allen mitgelesen und mitgestaltet werden, die ihn abonniert haben. So lässt sich die Kommunikation im Projekt thematisch ordnen und offen führen (vgl. Abb., (1)).
• Private Kanäle. Soll es in einem Team Bereiche geben, in denen nur eingeladene Mitglieder kommunizieren, können private Kanäle eingerichtet werden. Diese sind unsichtbar für Außenstehende und können bspw. vom Dozententeam verwendet werden, wenn Mattermost in der Lehre zum Einsatz kommt (vgl. Abb., (2)).
• Direktnachrichten. Für einen direkten Austausch zwischen allen Nutzer_innen von Mattermost an der TUHH steht letztlich die Funktion zur Verfügung, Direktnachrichten zu verschicken. Es können auch adhoc-Gruppen kommunizieren, indem mehrere Teilnehmende in einen Chat mit Direktnachrichten einbezogen werden (vgl. Abb., (3)).

Nachrichtenflut organisieren

Insbesondere wenn viele Menschen in einem Team zusammenkommen, kann es leicht passieren, dass einzelne Nachrichten untergehen. Dagegen gibt es einige leichte Tipps und Tricks, die den Umgang mit vielen Nachrichten vereinfachen:

• Anzeigen ungelesener Nachrichten: Oben links in der Seitenleiste kann man durch Klick auf den eigenen Namen die Kontoeinstellungen Unter Seitenleiste > Kanalgruppierung und -sortierung einfach einen Haken bei „Ungelesene separat gruppieren“ setzen und schon werden ungelesene Nachrichten oben in der Seitenleiste gebündelt dargestellt.
• Direkte Ansprache von einzelnen Personen: Wenn einzelne Personen in einem Kanal direkt angesprochen werden, kann dies über @benutzername gemacht werden. Der Vorteil ist, dass die Person direkt eine Benachrichtigung darüber bekommt.
• Antworten auf Nachrichten: Um die unterschiedlichen Gesprächsstränge in einem Kanal etwas zu strukturieren, sollten Antworten auf eine Nachricht über den Antwortpfeil rechts neben der Nachricht erfolgen. So werden alle Nachrichten und Antworten zu einem Thema in einem sogenannten Thread zusammengefasst.
• Markieren von zentralen Nachrichten: Zentrale Nachrichten, die für alle Teammitglieder interessant und relevant sind, können manuell mit einem digitalen Pin versehen werden, damit sie unter der Fülle von Nachrichten nicht untergehen. Diese gepinnten Nachrichten können in dem jeweiligen Kanal über das Stecknadel/Reißzwecken-Symbol oben rechts eingesehen werden.

Dateiablage individuell aushandeln

Wenngleich Mattermost die Möglichkeit bietet, auch Dateien im Chat zu teilen, empfiehlt es sich, davon wenig Gebrauch zu machen. Denn die Erfahrung zeigt, dass die Dateien schlecht wiedergefunden werden können, wenn sie erst einmal im Stream verschwunden sind. Auch ist oft nicht klar, welches die letzte verlässliche Version einer Datei ist.

Aus diesen Gründen sind wir dazu übergegangen, Dateien an anderen Orten zu speichern, und im Chat nur die Orte zu benennen, wo sie zu finden sind. Dieses Vorgehen ermöglicht allen Beteiligten, in ihren Projekten die Orte der Dateiablage individuell auszuhandeln. Nextcloud oder GitLab an der TUHH kommen hier in Frage, aber auch proprietäre Dienste von Drittanbietern.

Proaktives und empathisches Teilen

Wie Hand (2016b) aufzeigt, kann die Kommunikation in Tools wie Mattermost die Empathie für andere Teammitglieder und deren Aufgaben erhöhen. Während Linkempfehlungen per Mail noch nie gut gelitten waren, sind Hinweise auf Quellen, die andere im Team interessieren könnten, in Mattermost keine Last, sondern eine Bereicherung. Am ITBH pflegen wir in diesem Sinne das proaktive Teilen von Informationen, von denen wir denken, andere sollten sie auch haben. Sich dafür zu bedanken, ist nicht unbedingt notwendig, kann aber sehr unaufwändig mit einem Emoji geschehen.

Aktivitäten im Blick behalten

Mattermost wirbt damit, mehrere hundert Apps von Drittanbietern integrieren zu können. Wir nutzen dieses Potenzial am Institut bisher nicht, weil noch niemand danach verlangt hat. Eine Integration, die wir intensiv nutzen und die Entwicklungsgeschwindigkeit von Text- und Softwareprojekten sehr beschleunigt, ist GitLab. In dedizierten Bot-Kanälen lassen wir uns über Ereignisse in GitLab informieren. Wenn bspw. jemand ein neues Issue anlegt, Dateien ergänzt oder neu hochgeladen werden oder Buildpipelines scheitern, meldet GitLab das Ereignis in Mattermost. So können wir schnell darauf reagieren.

Mattermost spielt seine Stärken in der synchronen Kommunikation genauso aus wie in der asynchronen. Wenn alle während der üblichen Bürostunden an ihren Rechnern sitzen – im Institut oder im Home Office – ist der Austausch über Mattermost wesentlich schneller und präziser als per Mail. Da es oft um Texte, Formeln, Codeschnipsel und Links auf Dateiablageorte geht, ergänzt Mattermost das persönliche Gespräch sinnvoll. Aber auch in der Zusammenarbeit mit studentischen Hilfkräften und Tutor_innen leistet Mattermost gute Dienste. Sie können an ihren oft wechselnden Arbeitstagen die vergangene Kommunikation im Projekt nachvollziehen und sich schnell wieder auf den Stand bringen.

Mattermost in der Lehre

2017 hat Axel Dürkop Mattermost erstmals in der asynchronen Betreuung von Studierenden eingesetzt und damit bisher ganz gute Erfolge gehabt. Die Herausforderungen liegen dabei nicht in der Benutzung des Tools. Vielmehr ist die Frage zunächst, wie Mattermost so attraktiv gemacht werden kann, dass es an die Stelle von WhatsApp tritt, das Studierende bisher sehr häufig für den Austausch innerhalb ihrer Kohorten einsetzen. Das Argument ist stets, dass wenn sie auf die Unterstützung von Axel Dürkop als Dozent Wert legen, sie sich über Mattermost an ihn wenden müssen. Wenn er eine Mail bekommt, bittet er darum, die Frage oder das Anliegen noch einmal in Mattermost zu formulieren – außer, es handelt sich um persönliche Angelegenheiten. Oft bekommt er dann eine Direktnachricht, die er gern beantwortet. Gleichzeitig werden die Studierenden gefragt, ob sie sich nicht vorstellen können, ihre Anfrage auch in einem öffentlichen Kanal zu stellen. Manchmal ergeben sich daraus dann erweitere Diskussionen mit anderen Studierenden.

Eine weitere Herausforderung liegt darin, dass die Studierenden über die Woche zu sehr unterschiedlichen Zeiten an ihren Rechnern sitzen und die gestellten Aufgaben erledigen. Damit Tutor*in und Lehrende*r dann auch online sind, wurden die Projektteams im vergangenen Semester gebeten, ihre TOBOT (Time Of Being Online Together) bestimmen lassen. Wir haben dann versucht, auch zu diesen Zeiten online zu sein, um uns möglichst zeitnah in die verhandelten Probleme und Fragestellungen einmischen zu können – wenn diese transparent in öffentlichen Kanälen waren. Die Idee halten wir nach wie vor für sinnvoll, allerdings konnte diese lose Form der Verabredung aus unterschiedlichen Gründen nicht immer eingehalten werden.

Zwischenfazit

Mattermost in Forschung, Lehre und Softwareentwicklung birgt großes Potenzial. Am wichtigsten scheint – wie immer bei Prozessen, die einen Kulturwandel bedeuten – Geduld zu haben und nicht zu früh aufzugeben. Gegenüber meinen Kolleg_innen und Studierenden wurde immer deutlich gemacht, dass es darum geht, etwas auszuprobieren und dann gemeinsam zu schauen, ob dabei was Sinnvolles herauskommt. Und dies scheint im Rückblick nicht unwesentlich bei der Einführung der neuen Software zu sein: Alle Beteiligten als gleichberechtigte Mitwirkende in einem Experiment zu behandeln, deren Gewohnheiten, Erwartungen und Bedürfnisse ernst genommen werden müssen, wenn das Projekt gelingen soll.

Referenzen

4211: Axel Dürkop – Offene sozio-technische Systeme in Lehre und Forschung

Die preisgekrönte Software Jupyter Notebook ist in vielen Forschungsbereichen zum Defacto-Standard geworden. Bei der Entwicklung von Algorithmen, der Verarbeitung von Daten und der Zusammenarbeit in offenen Forschungsprozessen spielt die Software ihre Stärken aus. JupyterLab ist die Weiterentwicklung von Jupyter Notebook und bietet vor allem auf der Benutzeroberfläche einige sinnvolle Neuerungen (vgl. Abb. 1).

Loslegen mit Jupyter

Die klassische Arbeit in Jupyter Notebooks beginnt mit dem Import von Daten. Mit zahlreichen Skript- und Programmiersprachen können diese aufbereitet, analysiert und visualisiert werden. Unter den verfügbaren Kerneln befindet sich auch eins für Matlab, das in den Ingenieurwissenschaften nach wie vor stark verbreitet ist.

Da Jupyter Notebook mit so genannten Zellen arbeitet, können sich Codezellen und Textzellen abwechseln. Code wird direkt in den Zellen ausgeführt, Texte werden in Markdown verfasst. Dadurch können Hypothesen und Annahmen über die Daten formuliert und anschließend mithilfe von Code direkt überprüft werden. Die folgende Zelle hält dann die Beobachtung und Interpretation fest. So entstehen reproduzierbare Forschungstagebücher und im fortgeschrittenen Stadium publikationsreife Artikel. Abb. 2 zeigt an einem einfachen Beispiel die Verzahnung von Text und Code.

Was Burger und Notebooks gemeinsam haben

Die Jupytertools haben deshalb in vielen verschiedenen Domänen einen bedeutenden Stellenwert erlangt, weil sie den klassischen wissenschaftlichen Workflow so komprimiert abbilden wie ein Burger ein Dreigängemenü:

• Salat und Brot als Vorspeise
• Fleisch im Hauptgang und
• Käse zum Abschluss

Für Jupyter Notebook heißt das:

• Analysieren und erkennen
• Schreiben
• Publizieren

Wie auch der Hamburger die Abfolge der drei Gänge zeitlich und räumlich in sich vereint, finden auch in einem Notebook die drei Schritte des wissenschaftlichen Arbeitens zeitgleich und iterativ statt: Während ich forsche, schreibe ich auf, was ich beobachte, forsche mit neuen Erkenntnissen weiter, schreibe und schreibe und veröffentliche im besten Sinne von Open Science schon während des Forschungsprozesses meine Mitschriften und Daten.

Mein Forschungsergebnis veröffentliche ich dann am besten in einem Open-Access-Journal und zitiere darin den Digital Object Identifier (DOI), unter dem meine Notebooks zu finden sind. Den DOI habe ich von Zenodo bekommen, als ich dem Dienst einen Link zu meinem GitHub-Repo mit meinen Jupyter Notebooks gezeigt habe.¹ Der Journalartikel zusammen mit meinen Notebooks und Daten machen mein Forschungsergebnis und das Vorgehen transparent und nachvollziehbar.

Um es anderen Wissenschaftler_innen noch einfacher zu machen, nutze ich Tools wie binder, die es erlauben, Notebooks aus dem Git[Hub|Lab]-Repo direkt im Browser interaktiv nachzuvollziehen, um damit die Ergebnisse aus der Publikation zu reproduzieren und zu prüfen. Abb. 3 visualisiert diesen möglichen Workflow exemplarisch.

Über den folgenden Button

kann das Beispiel aus Abb. 2 direkt im Browser nachvollzogen werden. In der sich öffnenden Ansicht ist die Datei jupyter-beispiel.ipynb anzuklicken. Anschließend können die Zellen geändert und mit STRG+ENTER erneut ausgeführt werden.

Jupyter Notebook und JupyterLab laufen auf allen relevanten Betriebssystemen als Browsertool und können bspw. mithilfe von Anaconda auf dem eigenen Rechner installiert werden. Über eine serverseitige Installation von JupyterHub sind auch kollaborative Arbeiten an Daten- und Forschungsprojekten möglich.

Jupyter-Notebook-Installationen sind einfach über Plugins zu erweitern. So können z.B. mit RISE Präsentationen direkt aus Notebooks erstellt werden. Jede Zelle kann dabei zu einer eigenen Folie werden, in der der Code bei einer Präsentation live ausgeführt werden kann!

Jupyter an der TUHH

Die TUHH verfügt seit 2018 über einen JupyterHub, der im WiSe 2018/19 erstmals auch für elektronische Prüfungen eingesetzt wird. Zuvor hatten die Studierenden ein Semester lang eine handlungsorientierte Einführung in Machine-Learning-Grundlagen mit Python, wobei Jupyter Notebooks das zentrale Tool waren. Wir werden in diesem Blog noch ausführlich darüber berichten.

Weiterführende Links

Seit dem vergangenen Herbst kooperiert die Hamburg Open Online University (HOOU) mit den Bücherhallen Hamburg. In der Reihe “Open Your MINT – Gestalte deine digitale Zukunft!” finden im ersten Halbjahr 2019 verschiedene Workshops zu aktuellen HOOU-Projekten statt. Veranstaltungsort ist immer die Zentralbibliothek am Hühnerposten. Den Start in die Reihe machten wir am vergangenen Samstag, dem 02. Februar 2019, mit den Projekten tekethics (TUHH) und SciFiVisions (HCU/TUHH).

tekethics – Philosophische Annäherungen an aktuelle technische Entwicklungen

Blockchain, Big Data, Internet of Things, Virtual Reality, Augmented Reality, Robotik und Biotechnologie fordern Gesellschaften weltweit heraus, das technisch Machbare mit ihren Normen und Werten zu vereinbaren. Einfache Antworten sind rar, eine Frage zieht eine weitere nach sich und viele Technologien sind miteinander verbunden, was die Angelegenheit nochmals komplexer macht. Darüber hinaus wirken viele Technologien in ganz unterschiedliche Lebensbereiche hinein und irritieren unsere Traditionen und Gewohnheiten im Straßenverkehr, der Arbeitswelt, dem Gesundheitssystem, dem Wohnbereich, der Privatsphäre und der Sexualität (vgl. z.B. Specht, 2018).

Wie wirken sich intime Beziehungen zu Maschinen auf Mitmenschen aus?
Wer ist verantwortlich, wenn Maschinen bei der Arbeit Unfälle
verursachen?
Welche Verpflichtungen haben wir gegenüber künftigen Generationen und der Umwelt?
Verlieren Aspekte des Lebens an Bedeutung, wenn der Tod nicht mehr das Ende ist?

Das interessierte Publikum der Veranstaltung kam anhand dieser und anderer Fragen ins Gespräch miteinander und gründete am Ende der Veranstaltung einen Stammtisch, der sich regelmäßig mit Fragen im Spannungsfeld von Technik und Ethik beschäftigen möchte. Wir werden berichten, wenn dieser getagt hat.

SciFiVisions

In der zweiten Veranstaltung des Tages haben wir ähnliche Themen aufgegriffen, wie im tekethics Workshop, diese allerdings durch die kulturell-kreative Linse neu betrachtet. Ausgehend von unserem Verständnis, das Science Fiction (SF) eine Betrachtung möglicher Zukunft mit einem Fokus auf technologische Innovationen ist, haben wir die Diskussion damit gestartet, Zukunftsvisionen im SF-Film zu betrachten und verschiedene Szenarien danach abzuklopfen, wo wir bereits sind. Was vom Gezeigtem ist eigentlich als Imagination und was als direkte Fortführung des Ist-Zustands zu verstehen.

Wenn Wall-E über eine zugemüllte Erde düst, dann ist das in Anbetracht des Great Pacific Garbage Patch oder der riesigen Elektroschrottberge in Afrika keineswegs mehr eine ferne Zukunft. In der Diskussion ging es dann neben der Umweltverschmutzung (etwa in Wall-E – Der letzte räumt die Erde auf) auch um die Erderwärmung und die Flucht globaler Eliten in ihre Gated Communities oder, wie im Film Elysium, gar in den Weltraum. Ungleichheit und Ungerechtigkeit waren hier Stichworte, die auch eine Verbindung zur Robotik, der Automatisierung und dem Status von Arbeit (u.a. in Blade Runner und dem Kurzfilm Robots of Brixton) ermöglichten. Und schließlich haben wir uns über die ganz konkreten Lebenserfahrungen im Umgang mit sozialen Medien, der Abhängigkeit von Technologien für den Alltag und den Beziehungen im digitalen Zeitalter beschäftigt (u.a. im Film Her, der TV-Serie Black Mirror und dem Kurzfilm Strange Beasts).

Fortsetzung folgt

Wir beurteilen den Auftakt zu “Open Your MINT” positiv und freuen uns, dass auch das Veranstaltungsmanagement der Bücherhallen zufrieden war. Wir haben aber auch gelernt, dass die Diskussion über ethische Fragen aktueller Technologien, wie auch über deren kulturelle Darstellung, sehr voraussetzungsreich ist. Einige Teilnehmende äußerten, dass sie sich im tekethics Workshop zum ersten Mal mit den “Buzzwords” der Digitalisierung intensiv auseinandergesetzt hatten. Und im SciFiVisions Workshop fiel auf, dass die mitgebrachten Beispiele einem großen Teil des Publikums nicht präsent waren. Die HOOU-Projektleiter Axel (tekethics) und Lars (SciFiVisions) sind sich einig, dass in Zukunft die intensive Beschäftigung mit ein bis zwei technologischen Trends pro Workshop gut wäre und die Veranstaltungen dafür häufiger stattfinden könnten. Auch eine inhaltliche Vermischung, die Diskussion der ethischen Themen mit Beispielen aus der SF ist für uns denkbar. Die Bücherhallen haben sich in dieser Hinsicht für neue Ideen und Konzepte sehr offen gezeigt.

Material zur Veranstaltung

tekethics

Weiterführende Links und ein OER-Booklet zum Lernarrangement tekethics sind auf der Homepage des Projekts zu finden.

Specht, P. (2018). Die 50 wichtigsten Themen der Digitalisierung: künstliche Intelligenz, Blockchain, Bitcoin, Virtual Reality und vieles mehr verständlich erklärt (3. Auflage). München: REDLINE Verlag.

SciFiVisions

Weiterführende Links und ein OER-Booklet zum Lernarrangement SciFiVisions sind auf der Homepage des Projekts zu finden.

Docker ist eine moderne Form, Softwareanwendungen in virtuellen Containern auszuführen. Die Vorteile dieser Technik sind so zahlreich, dass Docker die IT-Welt im Sturm erobert hat (vgl. Vaughan-Nichols, 2018) und seit 2016 auch die TUHH.

Die Geschichte von Docker an der TUHH beginnt mit der Hamburg Open Online University (HOOU). Mittelfristiges Ziel des Großprojektes war es 2016, eine Lernplattform zu entwickeln, auf der die Lernarrangements der sechs staatlichen Hochschulen Hamburgs zum Mitmachen bereitgestellt werden sollten. Bis zur Fertigstellung der Plattform war jede Hochschule aufgefordert, die Ideen der Lehrenden “mit Bordmitteln” umzusetzen, mit vorhandenen Tools und aus der bisherigen Erfahrung mit E-Learning-Angeboten heraus. Die TUHH hat diesen Moment genutzt, um in ihrem wachsenden digitalen Experimentierfeld einige neue Technologien und Praktiken zu erproben und in den Kontext von Forschung und Lehre zu transferieren.

Die Motivation, Docker zu nutzen, entsprang zunächst einer praktischen Analyse der Software Sandstorm. Diese einzusetzen erschien aus zweierlei Gründen als technische Basis für die HOOU an der TUHH sinnvoll:

• Sandstorm ist freie Software und kann in Hochschulrechenzentren installiert werden.
• Sandstorm virtualisiert die verschiedenen Applikationen intern, erfordert also keinen dedizierten Rechner pro Anwendung.
• Sandstorm integriert eine Vielzahl von so genannten Web-2.0-Tools, die Anwender_innen unter einer einzigen Anmeldung zusammenziehen können.

Gerade aus dem dritten Grund schien Sandstorm bestens geeignet, die Grundlage für individuelle webgestützte Lernarrangements zu stellen. An der TUHH setzten wir Sandstorm in einer Entwicklungsumgebung auf und teilten unsere gewonnenen Erfahrungen mit den Kolleg_innen aus dem HOOU-Team. Begrüßt wurde die Übersicht der verschiedenen Typen von Anwendungen, die es als freie und quelloffene Software gab. Das Potenzial wurde auch darin gesehen, dass der App Market von Sandstorm und die einfache Inbetriebnahme der Applikationen vielen Lehrenden helfen würde, neue Anwendungen und Anwendungstypen kennenzulernen und auf neue und individuelle Ideen für ihre Lernarrangements zu kommen (vgl. Abb. 1).

Aus der Perspektive der Administration und Wartung allerdings erschien uns Sandstorm zu sehr als Blackbox, deren Innenleben wir nicht wirklich kontrollieren konnten. Auch war das technische Konzept der “Verpackung” von Anwendungen für Sandstorm, die Virtualisierung über Vagrant, zu umständlich, um die Entwicklungsgeschwindigkeit und Anpassbarkeit zu erreichen, die uns vorschwebte. Zudem war nicht klar, ob das Geschäftsmodell von Sandstorm langfristig tragen würde (vgl. Abschnitt “Chancen und Herausforderungen von Docker”). Sandstorm hatte uns inspiriert, aber nicht zufriedengestellt.

Der Einfluss von Software auf unsere Lebens- und Arbeitswelt wird immer deutlicher wahrnehmbar und verstärkt sich zusehends. So besteht bspw. das Internet, wie wir es heute in Form des World Wide Web hauptsächlich verwenden, nicht mehr nur aus statischen Webseiten, sondern aus komplexen Applikationen wie Shops oder sozialen Netzwerken. Auf unseren Mobiltelefonen befinden sich Apps, mit denen wir ständig interagieren und Daten austauschen, technische Geräte wie Waschmaschinen, Autos, Fahrkartenautomaten und Fernseher funktionieren nicht mehr ohne Software.

Software entsteht in interdisziplinärer Teamarbeit

U.a. aus diesem Grund ist eine oft gehörte Forderung dieser Tage, dass Menschen früh das Programmieren lernen sollten, um später in der Arbeitswelt bestehen zu können und besser zu verstehen, wie die Welt um uns herum funktioniert. Auch wenn diese Forderung vielleicht berechtigt ist und Grundkenntnisse der Softwareentwicklung in digitalen Zeiten nicht schaden können, liegt der eigentliche Kern der Sache woanders: Moderne Softwareanwendungen bestehen nicht nur aus dem Quellcode, der sie antreibt. Sie enthalten Informationen in Form von (bewegten) Bildern, Tönen, Texten und Daten, die erstellt und in die Anwendung integriert werden müssen. Häufig müssen die Anwendungen auch noch in zahlreiche weitere Sprachen übersetzt werden. Diese Aufgaben verteilen sich im Entwicklungsprozess von Software in der Regel auf ganz unterschiedliche Personen, Berufe und Professionen, und am Ende kommt ein multimediales digitales Produkt heraus, das durch Programmcode zusammengehalten wird und seine interne Logik und Funktionsweise erhält.

Was in diesem Sinne für Software gilt, ist auch auf digitale Medien allgemein übertragbar. Bücher sind heute zunächst immer digital vorhanden, auch wenn sie in einem letzten Schritt auf Papier gedruckt werden. Lehr-/Lernmaterialien in Form von PDF-Dokumenten, Webseiten oder Infografiken entstehen in der Regel durch Viele, die gemeinsam an einem Produkt arbeiten und ihren professionellen Teil dazu beitragen. Für eine technische Hochschule ist es daher nicht nur wichtig, das Programmieren zu lehren. Es ist heute ebenso wichtig, mit den Tools und Workflows vertraut zu machen, die Kollaboration und Teamarbeit an digitalen Artefakten erst ermöglichen. Software – und damit auch die Welt, in der wir in Zukunft leben werden – entsteht in interdisziplinärer Teamarbeit.

Daher sei an dieser Stelle die These gewagt, dass nicht jede und jeder unbedingt programmieren können muss. Wichtiger ist die Kenntnis von Kollaborationstools und -workflows, da sie auch nichtprogrammierende Menschen in die Lage versetzt, die digitale Zukunft mitzugestalten und sich aus seiner Profession heraus an digitalen Projekten beteiligen zu können. An der TUHH ebnen wir mit einer hauseigenen weltöffentlichen GitLab-Instanz dieser Kompetenzförderung den Weg.

Von der Open-Source-Bewegung lernen

GitLab ist eine Software zur dezentralen Zusammenarbeit an textbasierten digitalen Artefakten. Das bedeutet, dass Menschen weltweit verteilt, aber dennoch gemeinsam an Software, Webseiten, Texten und Datensammlungen arbeiten können. Sie müssen sich dazu nicht einmal persönlich kennen oder sehen und können doch Großes vereint zustande bringen. Diese Form der Kollaboration ist aus der Open-Source-Bewegung entstanden und erhielt 2005 neuen Schwung durch die Veröffentlichung von Git, einem Tool zur Verwaltung von Zwischenständen im Entwicklungsprozess von Software. Zu dieser Zeit war der Kollaborationsaspekt von Git noch nicht sehr ausgereift. Als 2008 das amerikanische Unternehmen GitHub mit seiner gleichnamigen Webplattform zum gemeinsamen Arbeiten an Code auf den Markt trat, veränderte sich die Entwicklungskultur der Open-Source-Gemeinschaft entscheidend: Durch den Mechanismus des Forkens ist es nicht mehr wie zuvor nötig, das Vertrauen einer Projektcommunity zu gewinnen, um Code beisteuern zu dürfen. Man fertigt nun online eine Kopie des Quellcodes an, verbessert ihn und stellt dann einen pull request an die Urheber_innen, mit dem diese aufgefordert werden, den Beitrag zu integrieren. Diesem Feature der Plattform ist es zuzuschreiben, dass sich die Entwicklung großer und kleiner Softwareprojekte im Open-Source-Umfeld rasant beschleunigte.

Die TUHH hostet eine eigene GitLab-Instanz

Für eine Hochschule stellt sich die Frage, ob die systematische Förderung von Kollaboration und Teamarbeit auf der proprietären Plattform GitHub im amerikanischen Rechtsraum strategisch klug ist. Rechtliche Aspekte in verschiedener Hinsicht sowie die Abhängigkeit von sich wandelnden Geschäftsmodellen im Startup-Sektor legen nahe, Alternativen im Bereich freier und quelloffener Software zu suchen. Aus diesen Gründen hat sich die TUHH entschieden, Kollaboration und Teamarbeit im skizzierten Sinne mit GitLab zu betreiben und aktiv zu fördern.

Seit dem 17. November 2016 hostet das Rechenzentrum der TUHH eine eigene GitLab-Instanz in der Community Edition. Der Prozess bis dahin ist eng verwoben mit dem HOOU-Projekt an der TUHH, in dem wir mit GitLab die ganzheitliche Entwicklung von Open Educational Resources (OER) implementiert haben. Am Prozess der Einrichtung und Bereitstellung des Dienstes waren und sind viele Akteur_innen der TUHH beteiligt, die gemeinsam daran arbeiteten, den Dienst weltöffentlich für alle Interessierten online zu stellen. Nichts Geringeres als interdisziplinäre und internationale Forschungs- und Lehrkooperationen sind das Ziel des öffentlichen GitLabs der TUHH. GitLab ist für viele Institute der Hochschule zu einem zentralen Werkzeug der Zusammenarbeit geworden, wir zählen bis heute über 1000 registrierte Nutzer_innen und entwickeln fortlaufend neue Ideen zum Einsatz in Forschung, Lehre und Projektmanagement.

Der Prozess bringt Akteur_innen näher zusammen

Darüber hinausgehend hat der Prozess der Einrichtung von GitLab viele Angehörige der TUHH in der Diskussion über die Digitalisierungsstrategie der Hochschule näher zusammengebracht. U.a. wurde die Arbeitsgruppe openTUHH gegründet, in der sich die Diskurse Open Education, Open Science und Open Access bündeln. Sie werden von verschiedenen Instituten, der TUHH-Bibliothek, dem Rechenzentrum und dem Präsidium verfolgt und gestaltet. Die Zusammenarbeit mit dem Datenschutzbeauftragten der TUHH hat dazu geführt, den Dienst von Anfang an sicher im Angebot der Hochschule zu verankern und alle Akteur_innen für die Anforderungen an Sicherheit, Datenschutz und verschiedene rechtliche Aspekte zu sensibilisieren. Schließlich hat sich eine monatliche Arbeitsgruppe zu GitLab herausgebildet, in der die Wünsche und Anforderungen der Nutzer_innen reflektiert werden, um die Nutzungsmöglichkeiten entsprechend anzupassen.

Zusammenfassung

Zu diesem Zeitpunkt können wir festhalten, dass GitLab mit seinen vielen technischen Möglichkeiten zahlreiche Nutzer_innen an der TUHH begeistert. Zudem zeigt der Prozess der Einrichtung und Bereitstellung, welche positiven Effekte sich auf verschiedenen Ebenen innerhalb der eigenen Hochschule ergeben können. In den zahlreichen Projekten, die wir bisher mit GitLab durchgeführt haben, haben sich Menschen mit unterschiedlichen Hintergründen, Erfahrungen und Kenntnissen produktive Teams gebildet, die gemeinsam freie Software und offene Bildungsressourcen entwickeln können.

Weitere Artikel zum Thema in diesem Blog

GitLab kam bisher in einer Reihe verschiedener Projekte zum Einsatz, die in den folgenden Beiträgen weiter ausgeführt werden:

• GitLab als CMS einsetzen

Weiterführende Links und Literatur

• Entwicklung einer offenen technischen Infrastruktur für HOOU-Lernarrangements an der TUHH im Blog der HOOU, 28.04.2016
• Ein technisches System für die kollaborative OER-Entwicklung im Experimentierfeld der TUHH im Blog der HOOU, 01.06.2017
• Bell, P. (2015). Introducing Github: A Non-Technical Guide. Sebastopol, CA: O’Reilly Media Inc.
• Hogbin Westby, E. J. (2015). Git for Teams. Sebastopol: O’Reilly.

Ziel dieses Tutorials

Das folgende Tutorial zeigt, wie ein GitLab-Projekt für das gemeinsame Schreiben eines Textes eingerichtet und GitLab im Sinne eines Content Management Systems (CMS) genutzt werden kann. Die Autor_innen erhalten immer ein fertiges PDF bzw. LibreOffice-Dokument, wenn sie in GitLab einen Text schreiben bzw. ändern.

Idee und Motivation

Tools und Plattformen für die gemeinsame Arbeit an Texten gibt es mittlerweile einige: GoogleDocs, Etherpads und Hackpads sind hierbei sicherlich die bekanntesten, Lösungen im Rahmen der bekannten Office-Suiten ergänzen das Spektrum.

Neben diesen vielen Möglichkeiten gehen wir an der TUHH noch einen anderen Weg beim kollaborativen Schreiben, indem wir GitLab im Sinne eines Content Management Systems (CMS) einsetzen. Motiviert ist dieser Ansatz dadurch, dass wir auch Menschen, die nicht programmieren, an partizipative und kollaborative Prozesse im Netz heranzuführen möchten, an deren Ende ein digitales Artefakt steht. Diese können in ausführbarer Software, in kompletten Webseiten oder auch nur in Textdokumenten bestehen. Mit dem kleinsten gemeinsamen Nenner, dem Schreiben, wollen wir alle an der gleichen Stelle abholen und den Grundstein für eine interdisziplinäre Zusammenarbeit legen.

Voraussetzungen

• ein Nutzeraccount in GitLab an der TUHH mit der Möglichkeit, eigene Projekte anzulegen
• Grundkenntnisse in Markdown

Los geht’s!

Anlegen eines neuen Projekts und der Beispieldateien¹

Zunächst legen wir in GitLab ein neues Projekt an. Dabei ist nichts Besonderes zu beachten. Nun erstellen wir drei neue Markdown-Dokumente mit Beispieltexten, einleitung.md, hauptteil.md und schluss.md. Das Tutorial funktioniert auch mit einer einzigen Datei, wir wollen aber schon an dieser Stelle die Zusammenarbeit mit mehreren vorbereiten. So könnten unterschiedliche Autor_innen für einzelne Teile bzw. Dateien in einem größeren Text- oder Softwareprojekt zuständig sein.

Die README.md wurde beim Anlegen des Projekts erstellt. Die Blindtexte stammen aus dem Blindtextgenerator. Wichtig: Die Dokumente sollten eine Leerzeile vor der ersten Überschrift enthalten, damit die Markdowndateien bei Zusammenfügen richtig erkannt werden.²

Artefakte erzeugen: PDF- und LibreOffice-Dokumente

Ziel des nächsten Schrittes ist es, aus dem “Quellcode”, also unseren Markdowntexten, ein PDF bzw. LibreOffice-Dokument zu erstellen. Dieser Vorgang steht stellvertretend für einen Prozess, der continuous integration genannt wird und sich mittlerweile in der Softwareentwicklung etabliert hat. Kurz gesagt bedeutet er, dass neue Beiträge zum Quellcode kontinuierlich in das Gesamtprodukt einfließen und nach kurzer Zeit immer ein verbessertes und funktionsfähiges Produkt zur Verfügung steht.

Was wir in den folgenden Schritten tun, ist demnach nicht nur für den beschränkten Rahmen dieses Tutorials relevant. Vielmehr handelt es sich um Wissen, durch das die Mitarbeit auch in komplexeren Projekten möglich ist. Also – weiter!

Die Zutaten

Wir brauchen für nun folgenden Schritte vier Zutaten:

• pandoc, ein kommandozeilenbasiertes Konvertierungstool, das aus unseren Markdowndateien die Zieldateien generiert
• Docker, eine schlanke Virtualisierungslösung, die uns Container mit pandoc zur Verfügung stellen soll. In diesen Containern werden online unsere Zieldateien generiert.
• einen GitLab Runner. Dabei handelt es sich um ein Programm, das wir beauftragen können, etwas ganz Bestimmtes für uns zu tun, wenn bestimmte Ereignisse eintreten. Es wird dafür sorgen, dass bei jeder Änderung einer Markdowndatei ein Dockercontainer gestartet wird, in dem mit pandoc die Zieldateien generiert werden.
• eine Datei .gitlab-ci.yml, in der die bisherigen Zutaten entsprechend konfiguriert werden.

Die Konfiguration der Pipeline

Um continuous integration für unser Beispiel zu konfigurieren, verwenden wir die folgende .gitlab-ci.yml-Datei. Sie ist im Hauptverzeichnis unseres Repos anzulegen.³ In der offiziellen Dokumentation ist sehr ausführlich beschrieben, was hier noch zu welchem Zweck eingestellt werden kann.

image: marcelhuberfoo/pandoc-gitit

build:
  script:
    - pandoc *.md -o bericht.pdf 
    - pandoc *.md -o bericht.odt
  artifacts:
    paths:
      - "*.pdf"
      - "*.odt"

In der ersten Zeile steht, welches Dockerimage wir verwenden wollen. Das angegebene funktioniert gut, baut allerdings noch nicht auf der aktuellen Version 2.0 von pandoc auf. Es liegt bei Dockerhub und kann auch gegen andere oder eigene Images ausgetauscht werden.

In den restlichen Zeilen ist angegeben, welches Kommando in dem Dockercontainer ausgeführt werden soll, der jedes Mal vom GitLab Runner gestartet wird, um unsere Dokumente zu bauen.

Dabei sorgen die Zeilen

- pandoc *.md -o bericht.pdf 
- pandoc *.md -o bericht.odt

dafür, dass aus allen Markdowndateien im Verzeichnis die finalen Dokumente gebaut werden. Die Reihenfolge, in der wir die sie aneinanderhängen, ergibt sich aus der Nummerierung im Dateinamen.⁴

Das angegebene Dockerimage enthält eine lauffähige Version von pandoc, sodass wir den Befehl pandoc mit entsprechenden Parametern hier geben können. Wir tun dies zweimal, um die beiden verschiedenen Dokumentformate zu erhalten.

In dem Block, der mit artifacts überschrieben ist, sagen wir, dass wir die Endprodukte der Pipeline, also das, was generiert wurde, behalten möchten. Der Dockercontainer schiebt dann diese Artefakte zurück in unsere GitLab-Projekt, wo wir sie herunterladen können.

Pipelines

Pipelines sind in GitLab definierte Abläufe, in denen verschiedene Stadien eines Bauvorgangs oder auch build process nacheinander und parallel abgearbeitet werden. Unsere Pipeline hier ist sehr einfach aufgebaut, sie hat genau eine Stufe (stage), die in der .gitlab-ci.yml mit build benannt ist.

Nachdem wir unsere .gitlab-ci.yml angelegt haben, versucht GitLab die Konfiguration darin abzuarbeiten. Das gelingt noch nicht gleich, wie wir unter CI/CD -> Pipelines sehen können.

Ein Klick auf das Label Pending führt zu einer nächsten Seite, die den Aufbau der Pipeline genauer darstellt. Hier taucht der Name unserer einzigen Stufe (stage) auf.

Ein weiterer Klick auf das Label build zeigt uns, woran es liegt:

Wir haben noch keinen Runner für unser Projekt zugewiesen, der für unsere Pipeline zuständig ist. Wenn wir dem Link in der Meldung, Runners Page, folgen, können wir dies nachholen.

Den GitLab Runner zuweisen

GitLab Runner sind dafür zuständig, Jobs für uns zu erledigen. Sie können auf unterschiedliche Weise konfiguriert werden, was in der offiziellen Dokumentation von GitLab ausführlich beschrieben wird.

Im GitLab der TUHH stehen momentan zwei Runner zur Verfügung, die von Nutzer_innen der Instanz verwendet werden können. Unter Settings -> CI/CD -> Runners können diese geteilten Runner mit einem Klick auf Enable shared Runners aktiviert werden.

Ein erneuter Blick auf die Übersicht der laufenden Pipelines über CI/CD -> Pipelines zeigt, dass nach einer Weile unsere Pipeline abgearbeitet wird.

Ein Klick auf die Label Passed und auf der folgenden Seite auf build zeigt, was stattgefunden hat:

Unser GitLab-Runner auf flint2 zieht sich das angegebene Dockerimage marcelhuberfoo/pandoc-gitit und startet darauf einen eigenen Container. In den Container, den man sich als schlanke virtuelle Maschine vorstellen kann, clont der Runner nun den Inhalt unseres Repositorys und damit auch die drei Markdowndateien.

Anschließend lässt er auf den Dateien des Repositorys die Befehle laufen, die wir in der .gitlab-ci.yml angegeben haben, um letztlich die generierten Artefakte aus dem Container wieder in GitLab hochzuladen. Der Container hat nun seinen Dienst erfüllt und wird gelöscht, die Pipeline ist erfolgreich durchgelaufen. Aber wo sind jetzt unsere Dateien?

Zugriff auf die Artefakte

Auf die generierten Artefakte kann an verschiedenen Stellen zugegriffen werden.

Artefakte, die zum Job gehören

Artefakte, die in einem speziellen Job erzeugt wurden, können rechts neben dem Job Log über die Button Keep, Download und Browse gefunden werden (s. Screenshot oben).

Artefakte der letzten erfolgreichen Pipeline

Auf der Homepage des Projekts können die Artefakte der letzten erfolgreichen Pipeline heruntergeladen werden.

Zusammenfassung und Ausblick

Wenn alles geklappt hat, sind wir nun in der Lage, mit mehreren Autor_innen an einem Textprojekt zu schreiben oder auch allein an einem größeren Projekt wie einer Qualifikationsarbeit oder einem Forschungsbericht.

Die Idee war, GitLab im Sinne eines CMS zu verwenden, um digitale Artefakte zu erzeugen. Der Content, den wir hier managen, sind die Markdowndateien, die Ausgabe erfolgt in einem PDF- bzw. LibreOffice-Dokument. In zukünftigen Tutorials werden wir uns ansehen, wie in dem gleichen Verfahren auch Webseiten gepflegt werden können. Der vorgestellte Ansatz ist übertragbar auf andere Szenarien und hat damit eine relativ große Reichweite. Mit anderen Worten: Es lohnt sich, die Lernkurve von GitLab zu erklimmen, weil es sich um sehr universelle Kenntnisse und Kompetenzen handelt.

Ausgehend von diesem Tutorial werden wir in Zukunft weitere Praktiken und Verfeinerungen betrachten. So ist es interessant zu sehen, wie das PDF-Dokument formatiert werden kann oder Bilder eingebunden werden können. Aber auch Workflows mit Fokus auf Kollaboration und Qualitätskontrolle sind zu betrachten.

Weiterführende Links und Literatur