<note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn1" n="1"> Zur Eignung speziell von GitHub und Versionierungsverwaltung als Digital Library s. die Studie von Minkova (2018). </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn2" n="2"> Git ( <ref target="https://git-scm.com/"> <hi rend="color(1155CC)">https://git-scm.com/</hi> </ref>), GitHub ( <ref target="https://github.com/"> <hi rend="color(1155CC)">https://github.com/</hi> </ref>), GitLab ( <ref target="https://gitlab.com/"> <hi rend="color(1155CC)">https://gitlab.com/</hi> </ref>). </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn3" n="3"> 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. </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn4" n="4"> 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. </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn5" n="5"> 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. </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn6" n="6"> 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. </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn7" n="7"> <hi style="font-size:10pt" xml:space="preserve">Siehe das laufende Portal "Niklas Luhmann-Archiv" unter </hi> <ref target="https://niklas-luhmann-archiv.de/"> <hi rend="color(1155CC)" style="font-size:10pt">https://niklas-luhmann-archiv.de/</hi> </ref> <hi style="font-size:10pt" xml:space="preserve"> .</hi> </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn8" n="8"> <hi style="font-size:10pt">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.</hi> </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn9" n="9"> Projektwebseite, Download und Dokumentation unter <ref target="https://github.com/apps/desktop"> <hi rend="color(1155CC)">https://github.com/apps/desktop</hi> </ref> . </note><note xmlns="http://www.tei-c.org/ns/1.0" rend="footnote text" xml:id="ftn10" n="10"> 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. </note>