reworked background structure, linked a lot more. Added Principles.

background/BACKGROUND.md

@@ -155,8 +155,8 @@ große Speicherkapazitäten – sind diese zu nennen.]{.aside}
   Beispielschritte direkt ausprobieren können. Idealerweise werden
   Code-Beispiele mit ausgegebenen Resultaten gezeigt (z. B. in Form von
   Ausschnitten oder, bei Kommandozeilentools, via `--help` dokumentiert).
-  [Faustregel: **Zeigen statt nur beschreiben** – konkrete Anwendungsfälle in
-  der Doku verankern.]{.aside}
+  [Prinpip 1: **Zeigen statt nur beschreiben – konkrete Anwendungsfälle in der
+  Doku verankern.**]{.aside .principle}
 
 ### Wissenschaftlicher Hintergrund und theoretischer Kontext
 
@@ -371,13 +371,7 @@ Software (und deren Doku) _auffindbar_ und _zugänglich_ zu machen, ohne Hürden
 Eine **gut gepflegte** README in [Markdown][] erfüllt diese Anforderungen in den
 meisten Fällen optimal.
 
-<!--
-
-Markierung für mich -.-
-
--->
-
-## Umfang und Fokus der Dokumentation
+## Die Dokumentation selbst
 
 Gerade weil Forschende wenig Zeit haben, muss die Dokumentation **effizient**
 gestaltet sein – sie soll alle wichtigen Informationen enthalten, aber auch
@@ -387,73 +381,194 @@ verteilt auf mehrere Dateien) als ausreichend erachtet. Dieser Richtwert
 verhindert, dass die Doku zu einer unüberschaubaren Abhandlung wird, und zwingt
 zur Fokussierung auf das Wesentliche. Wichtig ist der **Inhalt, nicht die
 Länge**: eine kürzere, aber inhaltsreiche Dokumentation ist besser als eine
-lange, die nichts aussagt.
+lange, die nichts aussagt. [Prinzip 1: **Kann eine neue Person in < 1 Stunde mit
+Hilfe der Doku das Tool zum Laufen bringen und ein einfaches Beispiel
+ausführen?**]{.aside .principle}
+
+### Umfang und Fokus der Dokumentation
+
+Ein effizienter Umfang lässt sich erreichen, indem sie **alles, was für
+Nachvollziehbarkeit und Wiederverwendung nötig ist dokumentieren, und alles
+andere skippen**. Negativbeispiele umfassen:
+
+- jeder interne Programmiertrick wird erläutert – Quellcode-Kommentare richten
+  sich an Entwickler, während die Nutzerdokumentation sich auf Nutzung und
+  Kontext beschränkt
+- seitenlange Theorieabhandlungen (verweisen Sie stattdessen auf Papers)
+- generische Erklärungen bekannter Technologien (man muss Git oder Python nicht
+  in der Doku erklären, sondern kann referenzieren)
+
+Halten Sie auch die Sprache prägnant:
+
+- kurze Absätze
+- Listen
+- und einfache Sätze
+
+erhöhen die Lesbarkeit.
 
-Ein effizienter Umfang lässt sich erreichen, indem man sich auf die oben
-genannten Kernpunkte konzentriert und Ablenkendes weglässt. Dokumentieren Sie
-**alles, was für Nachvollziehbarkeit und Wiederverwendung nötig ist, und skippen
-Sie alles andere**. Zum Beispiel muss nicht jeder interne Programmiertrick
-erläutert werden – Quellcode-Kommentare richten sich an Entwickler, während die
-Nutzerdokumentation sich auf Nutzung und Kontext beschränkt. Verzichten Sie auf
-seitenlange Theorieableitungen (verweisen Sie stattdessen auf Papers) und auf
-generische Erklärungen bekannter Technologien (man muss Git oder Python nicht in
-der Doku erklären, sondern kann referenzieren). Halten Sie auch die Sprache
-prägnant: kurze Absätze, Listen und einfache Sätze erhöhen die Lesbarkeit.
 Fachtermini aus dem jeweiligen wissenschaftlichen Bereich dürfen verwendet
-werden, aber erklären Sie sie, falls die Zielnutzer sie evtl. nicht kennen.
-
-**Priorisierung:** Beginnen Sie mit einer Minimaldokumentation, die alle
-Schlüsselaspekte abdeckt (_“keine Dokumentation”_ ist keine Option). _Good
-Enough Practices_ empfehlen, als ersten Schritt zumindest einen **kurzen
-erklärenden Kommentar am Anfang jedes Scripts** oder eine README mit ein paar
-Sätzen zu erstellen. Diese Hürde ist niedrig und bringt bereits Nutzen – selbst
-wenn (noch) keine ausführliche Handbuch-Doku existiert. Später kann die
-Dokumentation erweitert werden, insbesondere wenn die Software in Kooperation
-entsteht oder mehr Nutzer gewinnt. Es hat sich gezeigt, dass ausführliche
-Dokumentation oft erst entsteht, wenn ein echter Bedarf (z. B. durch externe
-Nutzer) vorhanden ist. Daher: zögern Sie nicht, zunächst _klein_ anzufangen,
-aber stellen Sie sicher, dass zumindest die kritischen Informationen sofort
-verfügbar sind (lieber ein 2-seitiges README heute, als das perfekte 30-seitige
-Handbuch in zwei Jahren, das evtl. nie geschrieben wird).
+werden, aber erklären/verlinken Sie sie, falls die Zielnutzer sie evtl. nicht
+kennen.
 
 Die Obergrenze von \~10 Seiten ist ein Richtwert. Umfangreiche Projekte könnten
 etwas mehr benötigen, sehr kleine Tools kommen mit einer Seite aus. Das Ziel
 ist, dass ein interessierter Nutzer die Dokumentation in überschaubarer Zeit
-durchsehen kann. Ein guter Test ist: **Kann eine neue Person in < 1 Stunde mit
-Hilfe der Doku das Tool zum Laufen bringen und ein einfaches Beispiel
-ausführen?** Wenn ja, ist der Detailgrad angemessen. Wenn die Person hingegen
-nach 10 Seiten immer noch nicht weiß, wie sie loslegen soll, muss die Doku
-fokussierter werden. Fügen Sie zur Not eine kurze _Übersicht/Zusammenfassung_ am
-Anfang ein, die das Wichtigste in Kürze nennt – viele Leser entscheiden in
-wenigen Minuten, ob sie eine Software weiter betrachten oder nicht, und hier
-zählt der erste Eindruck.
+durchsehen kann.
 
-Ein weiterer Tipp zur Effizienz: Nutzen Sie **Verweise und vorhandene
-Ressourcen**. Wenn z. B. Ihr Tool auf einem komplizierten Setup (Datenbank,
-Webserver) aufbaut, brauchen Sie nicht jede Installationsoption im Detail in
-Ihrer Doku zu reproduzieren – verlinken Sie auf offizielle
-Installationsanleitungen dieser Abhängigkeiten, und nennen Sie nur Ihre
-spezifischen Konfigurationen. Ebenso können Tutorials oder Papers, die schon
-existieren, als weiterführende Links angegeben werden, anstatt Inhalte redundant
-zu erklären. Das entlastet Ihre Dokumentation und hält sie schlank.
+Ein guter Test ist: **Kann eine neue Person in < 1 Stunde mit Hilfe der Doku das
+Tool zum Laufen bringen und ein einfaches Beispiel ausführen?**
 
-Zum Fokus gehört auch, zwischen **Nutzerdokumentation und
-Entwicklerdokumentation** zu unterscheiden. Dieser Katalog adressiert primär die
-Nutzerdokumentation (für Endnutzer und für die Autoren selbst, wenn sie das Tool
-später wieder anfassen). Entwicklerdokumentation (z. B. detaillierte
-API-Dokumente, Code-Kommentare, technische Architektur) kann separat gehalten
-werden, sofern nötig, um den Hauptnutzerfluss nicht zu überfrachten. Für viele
-kleine Forschungssoftware-Projekte sind ausführliche Entwicklerdokus nicht nötig
-– hier reicht es, den Code gut zu kommentieren und eventuell eine grobe
-Architekturübersicht bereitzustellen. Konzentrieren Sie die Hauptdokumentation
-darauf, **das Nutzen und Verstehen der Software von außen** zu ermöglichen.
+- Wenn ja, ist der Detailgrad angemessen
+- Wenn die Person hingegen nach 10 Seiten oder mehr als 1 Stunde immer noch
+  nicht weiß, wie sie loslegen soll, muss die Doku fokussierter werden.
 
-Abschließend sei betont: Ein kompakter, zielgerichteter Dokumentsatz, der genau
-die relevanten Infos liefert, erhöht die Wahrscheinlichkeit, dass er
-**aktualisiert und genutzt** wird. Umfangmonster schrecken ab und veralten
-schneller. Halten Sie die Dokumentation deshalb so **knapp wie möglich, aber so
-ausführlich wie nötig** – ganz im Sinne von Einsteins Prinzip, Dinge so einfach
-wie möglich zu machen, aber nicht einfacher.
+Fügen Sie zur Not eine kurze _Übersicht/Zusammenfassung_ am Anfang ein, die das
+Wichtigste in Kürze nennt – viele Leser entscheiden in wenigen Minuten, ob sie
+eine Software weiter betrachten oder nicht, und hier zählt der erste Eindruck.
+
+### Priorisierung bei Zeitmangel
+
+Dieser Katalog adressiert primär die Nutzerdokumentation (für Endnutzer und für
+die Autoren selbst, wenn sie das Tool später wieder anfassen).
+Entwicklerdokumentation (z. B. detaillierte API-Dokumente, Code-Kommentare,
+technische Architektur) kann separat gehalten werden, sofern nötig, um den
+Hauptnutzerfluss nicht zu überfrachten.
+
+#### Minimaldokumentation: kurze Kommentare
+
+Beginnen Sie mit einer Minimaldokumentation, die alle Schlüsselaspekte abdeckt
+(_“keine Dokumentation”_ ist keine Option). _Good Enough
+Practices_[@WilsonEtAl2017Goodenoughpractices] empfehlen, als ersten Schritt
+zumindest einen **kurzen erklärenden Kommentar am Anfang jedes Scripts** oder
+eine README mit ein paar Sätzen zu erstellen. Diese Hürde ist niedrig und bringt
+bereits Nutzen – selbst wenn (noch) keine ausführliche Handbuch-Doku existiert.
+Später kann die Dokumentation erweitert werden, insbesondere wenn die Software
+in Kooperation entsteht oder mehr Nutzer gewinnt. Es hat sich gezeigt, dass
+ausführliche Dokumentation oft erst entsteht, wenn ein echter Bedarf (z. B.
+durch externe Nutzer) vorhanden ist. Daher: zögern Sie nicht, zunächst _klein_
+anzufangen, aber stellen Sie sicher, dass zumindest die kritischen Informationen
+sofort verfügbar sind (lieber ein 2-seitiges README heute, als das perfekte
+30-seitige Handbuch in zwei Jahren, das evtl. nie geschrieben wird).
+
+#### Verlinkte Dokumentation ist auch Dokumentation
+
+Nutzen Sie **Verweise und vorhandene Ressourcen**. Wenn z. B. Ihr Tool auf einem
+komplizierten Setup (Datenbank, Webserver) aufbaut, brauchen Sie nicht jede
+Installationsoption im Detail in Ihrer Doku zu reproduzieren – verlinken Sie auf
+offizielle Installationsanleitungen dieser Abhängigkeiten, und nennen Sie nur
+Ihre spezifischen Konfigurationen und verlinken sie auf die Dokumentation des
+Setup-Elementes für alles weitere. Ebenso können Tutorials oder Papers, die
+schon existieren, als weiterführende Links angegeben werden, anstatt Inhalte
+redundant zu erklären. Das entlastet Ihre Dokumentation und hält sie schlank.
+
+#### Fokus auf Nutzer\*innen - nicht Entwickler\*innen
+
+Stellen Sie sich beim Schreiben der Doku die verschiedenen _Nutzerrollen_ vor:
+**“Zukünftiges Ich”**, **Kolleg\*innen**, **Fachforscher anderer Disziplin** und
+ggf. **Software-Entwickler, die den Code erweitern**. Jede dieser Gruppen möchte
+bestimmte Dinge wissen.
+
+_Forscher\*innen_ fragen:
+
+- Was kann das Tool?
+- Wie benutze ich es?
+- In welchem Kontext steht es?
+
+_Entwickler\*innen_ fragen:
+
+- Wie kann ich beitragen?
+- Wie funktioniert es unter der Haube?
+
+Priorisieren Sie zunächst die erstgenannten (Anwender) – deshalb Fokus auf
+Zweck, Nutzung und Ergebnisse in der Hauptdoku. Detailinfos für Entwickler
+(z. B. Code-Struktur, To-do-Liste) können separat oder später ergänzt werden.
+Für viele kleine Forschungssoftware-Projekte sind ausführliche Entwicklerdokus
+ohnehin nicht nötig – hier reicht es, den Code gut zu kommentieren und eventuell
+eine grobe Architekturübersicht bereitzustellen. Konzentrieren Sie die
+Hauptdokumentation darauf, **das Nutzen und Verstehen der Software von außen**
+zu ermöglichen.
+
+#### Und anschließend?
+
+Wenn der Zeitmangel vorüber ist[^als ob DAS je der Fall wäre -.-], sollte man
+nach und nach das folgende Kapitel umsetzen.
+
+## Was macht eine gute Dokumentation aus
+
+### Nutzungshilfen außerhalb der Dokumentation
+
+Falls Ihre Software ein **Command-Line Interface (CLI)** hat, stellen Sie
+sicher, dass eine eingebaute Hilfe vorhanden ist (z. B. Ausgabe bei `--help`).
+Viele Nutzer greifen zunächst darauf zurück. Dieses Hilfemenü sollte kurz
+erläutern, welche Subkommandos oder Optionen existieren. Moderne CLI-Frameworks
+generieren solche Hilfen oft automatisch aus Ihrem Code (z. B. [argparse][] in
+Python erzeugen `--help`-Texte). Nutzen Sie das, um konsistente Infos zu
+garantieren.
+
+Für **GUI-Anwendungen** sollten Tooltips, Hilfetexte in der Oberfläche oder
+zumindest ein kleiner _Help_-Abschnitt im Handbuch vorhanden sein. Diese
+eingebetteten Hilfen ersetzen keine ausführliche Dokumentation, aber sie senken
+die Schwelle für alltägliche Fragen.
+
+### Prinzipien: FAIR und ENDINGS
+
+Beachten Sie, dass dieser Anforderungskatalog in Einklang mit den Prinzipien des
+**Research Software Engineering**[@citation-needed] und den
+**ENDINGS-Prinzipien**[@EndingsPrinciples221] steht[Die ENDINGS-Prinzipien für
+digitale Projekte betonen insbesondere die Bedeutung von Dokumentation für
+Datenstrukturen, offenen Lizenzen, statischen Outputs und Zitierbarkeit. Unsere
+Empfehlungen, etwa ein statisches Markdown-README beizulegen, die
+Datenmodell-Doku nicht auszulagern oder Zitationsangaben zu machen, setzen genau
+diese Vorgaben um. ]{.aside}.
+
+Gute Dokumentation bedeutet daher u.a.
+
+- Reproduzierbarkeit (Installation, Daten, Beispiele),
+- Offenheit (Lizenz, offene Formate) und
+- Nachhaltigkeit (Versionierung, Langlebigkeit der Doku).
+
+Indem Sie also diesem Anforderungskatalog folgen, berücksichtigen Sie
+automatisch wichtige anerkannte Prinzipien für gute wissenschaftliche
+Softwarepraxis.
+
+### Kontinuierliche Verbesserung und Feedback
+
+Dokumentation ist kein einmaliges Ereignis, sondern ein fortlaufender Prozess.
+Best Practice sind daher insbesondere:
+
+- früh Feedback von Testnutzer\*innen oder Kolleg\*innen einzuholen: Lassen Sie
+  jemanden die Anleitung befolgen und hören Sie auf Stolpersteine. Oft zeigen
+  sich Lücken erst im Praxistest ("Ich wusste nicht, was ich nach Schritt X tun
+  soll" etc.).
+- Planen Sie Zeiten ein, die Dokumentation nachzuführen, insbesondere wenn sich
+  die Software ändert. Ein lebendiges Projekt wird vielleicht Release für
+  Release die Dokumentation erweitern (evtl. neue Tutorials, neue Module
+  dokumentieren). Spätestens zum Release-Zeitpunkt sollten diese auffallen und
+  ggf. als Issues adressiert werden.
+- Nutzen Sie auch _Issues_ für Dokumentation: Wenn Nutzer Fragen stellen,
+  überlegen Sie, ob die Antwort in die offizielle Doku übernommen werden sollte.
+  So wächst die Dokumentation organisch entlang der tatsächlichen Bedürfnisse.
+
+### Positiv- und Negativbeispiele studieren
+
+Schlussendlich ist ein guter Weg, die eigene Dokumentation zu verbessern, ist
+ein Blick auf Projekte mit exzellenter Doku. In der _[Journal of Open Source
+Software (JOSS)][JOSS]_ oder [_Journal of Open Research Software (JORS)_][JORS]
+werden oft Softwareartikel veröffentlicht, bei denen die zugehörigen
+Repositorien vorbildliche READMEs und Wikis haben. Diese können als Vorlage
+dienen.
+
+Achten Sie darauf, wie diese Projekte ihre README strukturieren, welche
+Abschnitte vorhanden sind und welche nicht. Viele erfolgreiche Projekte haben
+z. B. eine ähnliche Reihenfolge: Introduction, Installation, Usage,
+Contributing, License, Citation – ein Muster, das sich bewährt hat.
+
+Ebenso gibt es von Initiativen wie der Software Sustainability Institute
+Blogposts mit Best Practices und sogar Vorlagen (Templates) für Dokumentation.
+
+Nutzen Sie solche Ressourcen; sie ersparen einem das Rad neu zu erfinden.
+Allerdings: Adaptieren Sie sie auf Ihre Bedürfnisse – nicht jede Vorlage passt
+1:1.
 
 ## (Teil-)automatisierte Dokumentationswerkzeuge
 
@@ -464,57 +579,19 @@ aktuelle Unterlagen zu erhalten, ohne alles von Hand schreiben zu müssen. Im
 Folgenden werden einige Tools und Möglichkeiten vorgestellt – samt Empfehlungen,
 _wann_ ihr Einsatz sinnvoll oder notwendig ist:
 
-### Docstrings und API-Dokumentationsgeneratoren
-
-Nutzen Sie die Möglichkeit, Dokumentation _direkt im Quellcode_ unterzubringen,
-z. B. in Form von **Docstrings** (mehrzeilige Strings in Funktionen/Klassen bei
-Python, Roxygen-Kommentare in R, Javadoc-Kommentare in Java, etc.). Diese dienen
-doppelt: Zum einen erleichtern sie es Ihnen und Kollegen, den Code beim Lesen zu
-verstehen, zum anderen können sie von Tools ausgelesen und zu hübschen
-API-Dokumentationen verarbeitet werden. Idealerweise dokumentieren Sie _jede
-wichtige Funktion, Klasse oder Modul_ mit einem kurzen Docstring, der Zweck,
-Parameter, Rückgaben und ggf. Beispiele enthält. Für kleine Scripte genügen ggf.
-Modul- oder Abschnittskommentare. Wichtig ist Konsistenz im Stil – halten Sie
-sich an Konventionen Ihres Ökosystems (z. B. **Google Style Guide** für Python
-Docstrings oder entsprechende Formatvorgaben für andere Sprachen). Mit Tools wie
-**Sphinx** (für Python, aber grundsätzlich sprachunabhängig) können aus
-Docstrings automatisiert Webseiten oder PDF-Handbücher generiert werden. Sphinx
-liest z. B. die Python-Docstrings und erzeugt daraus strukturiert eine
-Dokumentation; Erweiterungen wie _napoleon_ erlauben es, Google- oder
-Numpy-Style-Dokumentation direkt zu verarbeiten.
-
-::: {.column-margin}
-
-Ähnliche Generatoren gibt es für nahezu alle Sprachen: **Javadoc** für Java,
-**Doxygen** für C/C++ (und viele andere Sprachen), **MkDocs** oder _pdoc_ für
-Python, etc.
-
-:::
-
-Der Einsatz solcher Tools ist besonders dann sinnvoll, wenn Ihre
-Forschungssoftware über eine _Programmierschnittstelle (API)_ verfügt, die von
-anderen genutzt werden soll, oder wenn das Projekt größer wird und die interne
-Struktur komplexer ist. In solchen Fällen kann eine _API-Referenz_ (automatisch
-aus dem Code erzeugt) eine erhebliche Hilfe sein. **Verpflichtend** wird dieser
-Ansatz etwa, wenn Sie ein Bibliothekspaket veröffentlichen (z. B. ein R-Package
-in CRAN oder Python-Package auf PyPI) – dort sind Docstrings und generierte
-Dokumentation quasi Standard. Für ein einmaliges Analyse-Skript in den Digital
-Humanities ist eine voll ausgebaute API-Doku vielleicht nicht nötig; hier reicht
-möglicherweise ein inline kommentierter Code. Doch sobald Funktionen von anderen
-aufgerufen oder das Projekt von mehreren entwickelt wird, sollte ein
-Dokumentationstool in Betracht gezogen werden, um den Aufwand gering zu halten
-und Einheitlichkeit zu gewährleisten.
-
 ### Jupyter Notebooks und literate programming
 
 Ein mächtiges Werkzeug – gerade in datengetriebenen Geisteswissenschaften – sind
-**Jupyter Notebooks** bzw. R Markdown Notebooks
+**Jupyter Notebooks** bzw. **R Markdown Notebooks**
 [@KluyverEtAl2016JupyterNotebookspublishing]. Diese erlauben es, _ausführbaren
 Code mit erklärendem Text und Visualisierungen_ in einem Dokument zu vereinen.
-Für Dokumentationszwecke können Notebooks zweierlei leisten: (1) als
-**Tutorials/Beispiel-Workflows**, die Nutzer interaktiv nachvollziehen können,
-und (2) als **Reproduzierbarkeits-Dokumentation** für analytische Prozesse. Wenn
-Ihre Forschungssoftware z. B. eine Bibliothek ist, könnten Sie ein Notebook
+Für Dokumentationszwecke können Notebooks zweierlei leisten:
+
+1. als **Tutorials/Beispiel-Workflows**, die Nutzer interaktiv nachvollziehen
+   können, und
+2. als **Reproduzierbarkeits-Dokumentation** für analytische Prozesse.
+
+Wenn Ihre Forschungssoftware z. B. eine Bibliothek ist, könnten Sie ein Notebook
 bereitstellen, das einen typischen Anwendungsfall durchspielt (inklusive
 Daten-Loading, Aufruf der Funktionen, Darstellung der Ergebnisse).
 
@@ -539,56 +616,97 @@ einsehbar sind.
 
 :::
 
-**Wann sind Notebooks verpflichtend?** – Nie im strengen Sinne, aber sie sind
-quasi Goldstandard, um wissenschaftliche Analysen nachvollziehbar zu machen. In
-Projekten, wo es um Data Science Workflows oder interaktive Exploration geht,
-sollten Notebooks stark erwogen werden, während für ein reines Tool/Script eine
-gut geschriebene README mit Beispielausgabe ausreichend sein kann.
+#### Wann sollten Sie Notebooks nutzen?
+
+Notebooks sind quasi Goldstandard, um wissenschaftliche Analysen nachvollziehbar
+zu machen. In Projekten, wo es um Data Science Workflows oder interaktive
+Exploration geht, sollten Notebooks stark erwogen werden, während für ein reines
+Tool/Script eine gut geschriebene README mit Beispielausgabe ausreichend sein
+kann.
 
 ### Sphinx/MkDocs/Doxygen (statische Dokumentationswebseiten)
 
 Für umfangreichere Projekte oder solche mit eigener Website kann es sinnvoll
-sein, eine **Dokumentationswebsite** zu generieren. Tools wie _Sphinx_ (zusammen
-mit ReadTheDocs für Hosting) oder _MkDocs_ erlauben es, aus
-Markdown/reStructuredText-Dateien einen ansprechend formatierten
+sein, eine **Dokumentationswebsite** zu generieren. Tools wie _[Sphinx][]_
+(zusammen mit ReadTheDocs für Hosting) oder _[MkDocs][]_ erlauben es, aus
+[Markdown][]/[reStructuredText][rst]-Dateien einen ansprechend formatierten
 HTML-Dokumentationssatz zu bauen. Der Vorteil ist, dass man eine durchsuchbare,
 verlinkte Doku bekommt, oft mit schönem Layout und zusätzlicher Navigation. Mit
 _Continuous Integration_ lassen sich diese Seiten bei jedem Git-Push automatisch
-aktualisieren. Für die Nachhaltigkeit (ENDINGS-Prinzip) ist wichtig, dass diese
-Webseiten statisch sind – d.h. sie funktionieren ohne Server-Backends und
-bleiben auch offline nutzbar. Sphinx erfüllt dies, indem es reine HTML-Seiten
-erzeugt. Solche Tools sind **sinnvoll, wenn die Dokumentation sehr groß oder
-öffentlich weit verbreitet** ist – z. B. wenn Ihre Software von vielen genutzt
-wird und Sie ein professionelles Auftreten wünschen, oder wenn Sie die Doku als
-PDF veröffentlichen möchten. [In kleinen DH-Projekten ist es oft nicht nötig,
-extra eine Webseite zu hosten; dennoch kann Sphinx auch lokal HTML/PDF erzeugen,
-was man dem Repo beilegen kann.]{.aside}
+aktualisieren. [Prinzip 2: **ab einer Codebasis `> einige tausend Zeilen` oder
+`>5 Module` lohnt es sich, eine generierte Dokumentation bereitzustellen, um
+(auch selbst) den Überblick zu behalten.**]{.aside .principle}
+
+Für die Nachhaltigkeit ist wichtig, dass diese Webseiten statisch
+sind[@EndingsPrinciples221] – d.h. sie funktionieren ohne Server-Backends und
+bleiben auch offline nutzbar.
+
+Solche Tools sind **sinnvoll, wenn die Dokumentation sehr groß oder öffentlich
+weit verbreitet** ist – z. B. wenn Ihre Software von vielen genutzt wird und Sie
+ein professionelles Auftreten wünschen, oder wenn Sie die Doku als PDF
+veröffentlichen möchten. [In kleinen DH-Projekten ist es oft nicht nötig, extra
+eine Webseite zu hosten; dennoch kann Sphinx auch lokal HTML/PDF erzeugen, was
+man dem Repo beilegen kann.]{.aside}
+
+#### Wann sollten Sie eine statische Website generieren?
 
 **Verpflichtend** ist so ein Tool selten, höchstens wenn Förderprogramme oder
 Journals ein dokumentationsseitiges HTML-Manual verlangen. Wenn Sie jedoch
 planen, Ihre Software z. B. über Jahre zu pflegen und ggf. einem Journal wie
 JOSS vorzustellen, dann erwartet die Community meist, dass zumindest eine
-Sphinx/Doxygen-Doku für die API existiert. Als Daumenregel: ab einer Codebasis >
-einige tausend Zeilen oder > 5 Module lohnt es sich, eine generierte
-Dokumentation bereitzustellen, um den Überblick zu behalten.
+Sphinx/Doxygen-Doku für die API (s.u.) existiert.
 
-### In-Code Hilfefunktionen und CL-Interface Doku
+### Docstrings und API-Dokumentationsgeneratoren
 
-Falls Ihre Software ein **Command-Line Interface (CLI)** hat, stellen Sie
-sicher, dass eine eingebaute Hilfe vorhanden ist (z. B. Ausgabe bei `--help`).
-Viele Nutzer greifen zunächst darauf zurück. Dieses Hilfemenü sollte kurz
-erläutern, welche Subkommandos oder Optionen existieren. Moderne CLI-Frameworks
-generieren solche Hilfen oft automatisch aus Ihrem Code (z. B. Click oder
-argparse in Python erzeugen `--help`-Texte). Nutzen Sie das, um konsistente
-Infos zu garantieren.
+Nutzen Sie die Möglichkeit, Dokumentation _direkt im Quellcode_ unterzubringen,
+z. B. in Form von **[Docstrings][Docstring]** (mehrzeilige Strings in
+Funktionen/Klassen bei Python, [Roxygen][]-Kommentare in R,
+[Javadoc][]-Kommentare in Java, etc.). Diese dienen doppelt: Zum einen
+erleichtern sie es Ihnen und Kollegen, den Code beim Lesen zu verstehen, zum
+anderen können sie von Tools ausgelesen und zu hübschen API-Dokumentationen
+verarbeitet werden. Idealerweise dokumentieren Sie _jede wichtige **oder** von
+außen sichtbare Funktion, Klasse oder Modul_ mit einem kurzen Docstring, der
+Zweck, Parameter, Rückgaben und ggf. Beispiele enthält. Für kleine Scripte
+genügen ggf. Modul- oder Abschnittskommentare.[Prinzip 3: **Benutzt jemand die
+Software nur braucht es keine API-Dokumentationen; wird die Software aber
+woanders eingebunden ist dieses angeraten.**]{.aside .principle}
 
-Für **GUI-Anwendungen** sollten Tooltips, Hilfetexte in der Oberfläche oder
-zumindest ein kleiner _Help_-Abschnitt im Handbuch vorhanden sein. Diese
-eingebetteten Hilfen ersetzen keine ausführliche Dokumentation, aber sie senken
-die Schwelle für alltägliche Fragen.
+Wichtig ist Konsistenz im Stil – halten Sie sich an Konventionen Ihres
+Ökosystems (z. B. **[Google Style Guide](https://google.github.io/styleguide/)**
+für Python Docstrings oder entsprechende Formatvorgaben für andere Sprachen).
+Verlinken sie diese Styleguides in der README. Sogenannte Linting-Tools, wie
+etwa [pylint][], können die Verwendung erzwingen.
+
+Mit Tools, wie **[Sphinx][]**, **[Javadoc][]**, **[Doxygen][]**,
+**[MkDocs][]**,**[pdoc][]** und vielen weiteren, können aus Docstrings
+automatisiert Webseiten oder PDF-Handbücher generiert werden. Sie lesen z. B.
+die Python-Docstrings und erzeuge daraus strukturiert eine Dokumentation; Häufig
+kann über Erweiterungen auch dritte Dokumentation direkt eingebunden und
+verlinkt werden.
+
+Der Einsatz solcher Tools ist besonders dann sinnvoll, wenn Ihre
+Forschungssoftware über eine _Programmierschnittstelle (API)_ verfügt, die von
+anderen genutzt werden soll, oder wenn das Projekt größer wird und die interne
+Struktur komplexer ist. In solchen Fällen kann eine _API-Referenz_ (automatisch
+aus dem Code erzeugt) eine erhebliche Hilfe sein.
+
+**Verpflichtend** wird dieser Ansatz etwa, wenn Sie ein Bibliothekspaket
+veröffentlichen (z. B. ein R-Package in CRAN oder Python-Package auf PyPI) –
+dort sind Docstrings und generierte Dokumentation quasi Standard. Für ein
+einmaliges Analyse-Skript in den Digital Humanities ist eine voll ausgebaute
+API-Doku vielleicht nicht nötig; hier reicht möglicherweise ein inline
+kommentierter Code. Häufig wandeln sich solche Analyse-Skripte aber über Zeit,
+sodass hier auch weitere Prinzipien guter Software[@citation-needed], wie
+Modularisierung empfohlen sind um gegebene Ansätze einfacher zu übertragen.
+[Prinzip: **Benutzt jemand die Software nur braucht es keine
+API-Dokumentationen; wird die Software aber woanders eingebunden ist dieses
+angeraten.**]{.aside .principle}
 
 ### Versionskontrolle und kontinuierliche Dokumentationspflege
 
+[Prinzip 4: **Die beste Dokumentation ist die, die sich selbst
+schreibt.**]{.aside .principle}
+
 Eine Form der _Teil-Automatisierung_ ist es, die Dokumentation an den
 Entwicklungs-Workflow zu koppeln. So sollte die Dokumentation im selben
 Versionskontrollsystem (Git) liegen wie der Code, damit Änderungen synchron
@@ -599,64 +717,16 @@ mit Continuous Integration (CI) kann man sogar automatisierte Checks einrichten,
 die z. B. prüfen, ob die Doku gebaut werden kann oder ob Docstrings fehlen.
 Einige CI-Skripte generieren bei jedem Commit eine frische Doku (z. B. mittels
 Sphinx) und veröffentlichen sie – so ist garantiert, dass _die aktuelle
-Codeversion immer eine aktuelle Doku hat_. [Dieses Level an Automation ist für
-kleine Projekte evtl. zu viel, aber das **Prinzip “Dokumentation versionieren”**
-ist allgemeingültig, um die Entwicklungshistorie konsistent zu halten.]{.aside}
-
-### Spezialfälle
-
-In bestimmten Fällen gibt es weitere Werkzeuge: z. B. **Doxygen** für
-automatisierte Code-Diagramme und Querverweise (gerne in C++-Projekten genutzt),
-oder **Swagger/OpenAPI** für automatische Dokumentation von Web-APIs. Wenn Ihre
-Forschungssoftware z. B. einen Webservice anbietet, kann Swagger eine
-interaktive API-Doku erzeugen. Ebenso können **Literatur-Manager** wie Manubot
-oder RMarkdown Bücher helfen, Code und Text zu integrieren (aber das geht über
-das hinaus, was die meisten DH-Projekte benötigen). Erwähnenswert ist noch
-**Jupyter Book** oder R **Bookdown**, womit man umfangreiche narrative
-Dokumentationen (inkl. Code) als Website/Book erstellen kann – nützlich, falls
-Ihre Dokumentation eher ein ausführlicher Lehrtext werden soll (z. B. wenn die
-Software einen ganzen methodischen Ansatz dokumentiert). Für den hier
-anvisierten Zweck (knackiger Doku-Katalog) sind solche Tools meist zu
-schwergewichtig.
-
-### Wann ist was verpflichtend
-
-Es gibt kein universelles Muss, außer: **Irgendeine Form der Doku ist Pflicht**.
-Ob Sie nun per Hand Markdown schreiben oder Sphinx einsetzen, hängt von Kontext
-und Projektgröße ab. Allgemein gilt: Verwenden Sie Automatisierung wo immer
-möglich, _um sich zu entlasten_, aber vermeiden Sie Overhead durch Tools, die
-Sie nicht brauchen. Ein einzelnes historisches Analyse-Skript braucht kein
-Doxygen; ein komplexes DH-Toolkit mit API sollte hingegen Doxygen oder Sphinx
-nutzen, damit die Nutzer nicht den Code lesen müssen, um Funktionen zu
-verstehen. Denken Sie daran: _“Die beste Dokumentation ist die, die sich selbst
-schreibt.”_ – dieses Motto aus der Literatur spielt darauf an, dass wir Tools
-nutzen sollen, die uns Schreibarbeit abnehmen. Perfekt autonom schreibt sich die
-Dokumentation zwar nie, aber moderne Werkzeuge können Routineaufgaben (z. B.
-Inhaltsverzeichnisse, Funktionsreferenzen, Formatierung) automatisieren. Dadurch
-bleibt Ihnen mehr Zeit für das inhaltliche Fine-Tuning der Texte.
+Codeversion immer eine aktuelle Doku hat_. [Prinzip: **Dieses Level an
+Automation ist für kleine Projekte evtl. zu viel, aber das Prinzip
+“Dokumentation versionieren” ist allgemeingültig, um die Entwicklungshistorie
+konsistent zu halten.**]{.aside}
 
 ## Best Practices, Vorlagen und Checklisten
 
-Um zu entscheiden, _was_ dokumentiert wird (und was nicht), helfen etablierte
+Um zu entscheiden, _was_ dokumentiert wird (und was _nicht_), helfen etablierte
 **Best Practices** sowie Vorlagen aus der Community. Im Folgenden sind einige
-bewährte Richtlinien zusammengefasst, untermauert von Quellen, die bei der
-Priorisierung der Dokumentationsinhalte helfen:
-
-### Orientierung an Nutzerbedürfnissen
-
-Stellen Sie sich beim Schreiben der Doku die verschiedenen _Nutzerrollen_ vor:
-**“Zukünftiges Ich”**, **Kolleg\*innen**, **Fachforscher anderer Disziplin** und
-ggf. **Software-Entwickler, die den Code erweitern**. Jede dieser Gruppen möchte
-bestimmte Dinge wissen. _Forscher\*innen_ fragen: _Was kann das Tool? Wie
-benutze ich es? In welchem Kontext steht es?_. _Entwickler\*innen_ fragen: _Wie
-kann ich beitragen? Wie funktioniert es unter der Haube?_. Priorisieren Sie
-zunächst die erstgenannten (Anwender) – deshalb Fokus auf Zweck, Nutzung und
-Ergebnisse in der Hauptdoku. Detailinfos für Entwickler (z. B. Code-Struktur,
-To-do-Liste) können separat oder später ergänzt werden. Halten Sie sich stets
-vor Augen: **Dokumentation ist primär für Menschen** (nicht für Maschinen),
-daher schreiben Sie klar und vermeiden Sie unnötigen Jargon. _Selbst wenn der
-Code “für sich spricht”_, denken Sie daran, dass klare Erläuterungen später viel
-Zeit sparen.
+bewährte Richtlinien zusammengefasst.
 
 ### Checkliste für die Mindest-Dokumentation
 
@@ -704,72 +774,17 @@ Dokumentation zu überprüfen:
     abschrecken.
 
 Diese Checkliste kann vor einem “Release” der Software durchgegangen werden,
-ähnlich einem Review-Prozess (vgl. JOSS Review-Kriterien, die viele dieser
-Punkte abdecken). Sie hilft zu entscheiden, was noch dokumentiert werden muss
-und was eventuell weggelassen werden kann. **Alles, was für die obigen Punkte
-nicht relevant ist, kann man tendenziell aus der Hauptdokumentation
-herauslassen.** Beispielsweise interne Code-Refaktorierungsdetails oder
-historische Anekdoten zur Entwicklung gehören eher ins interne Changelog oder in
-Blog-Posts, nicht in die Nutzerdokumentation.
-
-### Positiv- und Negativbeispiele studieren
-
-Ein guter Weg, die eigene Dokumentation zu verbessern, ist ein Blick auf
-Projekte mit exzellenter Doku. In der _Journal of Open Source Software (JOSS)_
-oder _Journal of Open Research Software (JORS)_ werden oft Softwareartikel
-veröffentlicht, bei denen die zugehörigen Repositorien vorbildliche READMEs und
-Wikis haben. Diese können als Vorlage dienen. Achten Sie darauf, wie diese
-Projekte ihre README strukturieren, welche Abschnitte vorhanden sind und welche
-nicht. Viele erfolgreiche Projekte haben z. B. eine ähnliche Reihenfolge:
-Introduction, Installation, Usage, Contributing, License, Citation – ein Muster,
-das sich bewährt hat. Ebenso gibt es von Initiativen wie der Software
-Sustainability Institute Blogposts mit Best Practices und sogar Vorlagen
-(Templates) für Dokumentation. Nutzen Sie solche Ressourcen; sie ersparen einem
-das Rad neu zu erfinden. Allerdings: Adaptieren Sie sie auf Ihre Bedürfnisse –
-nicht jede Vorlage passt 1:1.
-
-### Prinzipien: FAIR und ENDINGS
-
-Beachten Sie, dass dieser Anforderungskatalog in Einklang mit den Prinzipien des
-**Research Software Engineering** und den **ENDINGS-Prinzipien** steht. Gutes
-Research Software Engineering fördert u.a. _Nachhaltigkeit, Offenheit und
-Reproduzierbarkeit_ in der Softwareentwicklung. Dementsprechend legt unsere
-Dokumentations-Checkliste Wert auf Reproduzierbarkeit (Installation, Daten,
-Beispiele), Offenheit (Lizenz, offene Formate) und Nachhaltigkeit
-(Versionierung, Langlebigkeit der Doku). Die ENDINGS-Prinzipien für digitale
-Projekte betonen insbesondere die Bedeutung von Dokumentation für
-Datenstrukturen, offenen Lizenzen, statischen Outputs und Zitierbarkeit. Unsere
-Empfehlungen, etwa ein statisches Markdown-README beizulegen, die
-Datenmodell-Doku nicht auszulagern oder Zitationsangaben zu machen, setzen genau
-diese Vorgaben um. Indem Sie also diesem Anforderungskatalog folgen,
-berücksichtigen Sie automatisch wichtige anerkannte Prinzipien für gute
-wissenschaftliche Softwarepraxis.
-
-### Kontinuierliche Verbesserung und Feedback
-
-Dokumentation ist kein einmaliges Ereignis, sondern ein fortlaufender Prozess.
-Best Practice ist, früh Feedback von Testnutzer\*innen oder Kolleg\*innen
-einzuholen: Lassen Sie jemanden die Anleitung befolgen und hören Sie auf
-Stolpersteine. Oft zeigen sich Lücken erst im Praxistest ("Ich wusste nicht, was
-ich nach Schritt X tun soll" etc.). Planen Sie Zeiten ein, die Dokumentation
-nachzuführen, insbesondere wenn sich die Software ändert. Ein lebendiges Projekt
-wird vielleicht Release für Release die Dokumentation erweitern (evtl. neue
-Tutorials, neue Module dokumentieren). Nutzen Sie auch _Issues_ für
-Dokumentation: Wenn Nutzer Fragen stellen, überlegen Sie, ob die Antwort in die
-offizielle Doku übernommen werden sollte. So wächst die Dokumentation organisch
-entlang der tatsächlichen Bedürfnisse.
+ähnlich einem Review-Prozess (vgl.
+[JOSS Review-Kriterien](https://joss.readthedocs.io/en/latest/review_checklist.html),
+die viele dieser Punkte abdecken). Sie hilft zu entscheiden, was noch
+dokumentiert werden muss und was eventuell weggelassen werden kann. **Alles, was
+für die obigen Punkte nicht relevant ist, kann man tendenziell aus der
+Hauptdokumentation herauslassen.** Beispielsweise interne
+Code-Refaktorierungsdetails oder historische Anekdoten zur Entwicklung gehören
+eher ins interne Changelog oder in Blog-Posts, nicht in die Nutzerdokumentation.
 
 ### Zusammenfassung Best Practices
 
-Zusammenfassend helfen die genannten Best Practices dabei, die Dokumentation
-**zielgerichtet** zu gestalten: Dokumentiert wird, was dem Verständnis und der
-Nutzung dient; weggelassen wird, was überflüssig oder selbstverständlich ist.
-Eine gute Dokumentation _erzählt eine klare Geschichte_ über die Software,
-anstatt den Leser mit irrelevanten Details zu verlieren. Mit den richtigen
-Werkzeugen und Prinzipien an der Hand kann selbst unter Zeitdruck eine
-qualitativ hochwertige Dokumentation entstehen – zur Freude aller, die mit der
-Forschungssoftware arbeiten möchten.
-
 ## Fazit
 
 Die hier präsentierten Anforderungen und Empfehlungen bieten einen **Leitfaden
@@ -781,23 +796,29 @@ dokumentiert, ein nutzerfreundliches Format (README im Repo) gewählt, der Umfan
 fokussiert gehalten und hilfreiche Tools eingesetzt werden, kann die
 Dokumentation zur Stärke eines Projekts werden statt einem lästigen Anhängsel.
 
-Wissenschaftlich fundierte Best Practices – von _Ten Simple Rules for
-Documenting Scientific Software_ bis zu den _ENDINGS-Principles_ – untermauern
-diesen Katalog. Die Umsetzung dieser Richtlinien wird dazu beitragen, dass
-Forschungssoftware aus den Geisteswissenschaften nicht nur kurzfristig von ihren
-Autor\*innen genutzt wird, sondern langfristig von Dritten verstanden, validiert
-und weiterentwickelt werden kann. So schließt sich der Kreis zwischen guter
-**Softwareentwicklung** und guter **Wissenschaft**: Dokumentation ist das
-Bindeglied, das Code und Erkenntnis transparent verbindet. In der Praxis
-bedeutet dies zwar zusätzliche Arbeitsschritte, doch wie die Erfahrung zeigt,
-zahlen sich diese in Form von _Zeiteinsparung bei Nutzern, höherer Zitierbarkeit
-und größerer Wirkung_ der Software aus. Mit diesem Anforderungskatalog sind
-Forschende gut gerüstet, um ihre Softwareprojekte dokumentationstechnisch auf
-ein solides Fundament zu stellen – trotz knapper Zeit und ohne
-Informatikabschluss. Denn am Ende gilt: **Gut dokumentierte Forschungscode ist
-nachhaltige Forschung**.
+Eine gute Dokumentation _erzählt eine klare Geschichte_ über die Software,
+anstatt den Leser mit irrelevanten Details zu verlieren. Mit den richtigen
+Werkzeugen und Prinzipien an der Hand kann selbst unter Zeitdruck eine
+qualitativ hochwertige Dokumentation entstehen – zur Freude aller, die mit der
+Forschungssoftware arbeiten möchten.
 
-### Tabellarische Übersicht der Dokumentations-Bestandteile
+Wissenschaftlich fundierte Best Practices – von _Ten Simple Rules for
+Documenting Scientific Software_[@PrlicProcter2012TenSimpleRules] bis zu den
+_ENDINGS-Principles_[@EndingsPrinciples221] – untermauern diesen Katalog. Die
+Umsetzung dieser Richtlinien wird dazu beitragen, dass Forschungssoftware aus
+den Geisteswissenschaften nicht nur kurzfristig von ihren Autor\*innen genutzt
+wird, sondern langfristig von Dritten verstanden, validiert und weiterentwickelt
+werden kann. So schließt sich der Kreis zwischen guter **Softwareentwicklung**
+und guter **Wissenschaft**: Dokumentation ist das Bindeglied, das Code und
+Erkenntnis transparent verbindet. In der Praxis bedeutet dies zwar zusätzliche
+Arbeitsschritte, doch wie die Erfahrung zeigt, zahlen sich diese in Form von
+_Zeiteinsparung bei Nutzern, höherer Zitierbarkeit und größerer Wirkung_ der
+Software aus. Mit diesem Anforderungskatalog sind Forschende gut gerüstet, um
+ihre Softwareprojekte dokumentationstechnisch auf ein solides Fundament zu
+stellen – trotz knapper Zeit und ohne Informatikabschluss. Denn am Ende gilt:
+**Gut dokumentierte Forschungscode ist nachhaltige Forschung**.
+
+## Tabellarische Übersicht der Dokumentations-Bestandteile {.appendix}
 
 ::: {.column-page-right}
 
@@ -820,16 +841,6 @@ sollte. Je nach Projekt können einige Elemente wegfallen oder kombiniert werden
 
 :::
 
-### Schlusswort
-
-Mit einer solchen Struktur und Herangehensweise lässt sich auch in einem kleinen
-Forschungsteam eine professionelle Dokumentation erzielen, die den Prinzipien
-von Open Science und nachhaltiger Softwareentwicklung gerecht wird. Die
-investierte Mühe wird durch Zeitgewinn bei Wiederverwendung und Erweiterung der
-Software mehr als aufgewogen. So wird die Forschungssoftware nicht zum
-einmaligen “Nebenprodukt”, sondern zu einem robusten, teilbaren Ergebnis
-wissenschaftlicher Arbeit.
-
 ## Referenz Websites/Services {.appendix}
 
 - [GitHub][]: Seite mit sehr vielen Open-Source-Projekten, die git verwenden.
@@ -837,6 +848,22 @@ wissenschaftlicher Arbeit.
 - [GitLab][]: Open-Source-Lösung für selbst gehostete Projektverwaltung (git,
   issue-tracking, …). Community (kostenfrei; limitierte features) oder
   Enterprise-Linzenz
+- [JOSS][]: The Journal of Open Source Software is a developer friendly, open
+  access journal for research software packages.
+- [JORS][]: The Journal of Open Research Software features peer reviewed
+  Software Metapapers describing research software with high reuse potential.
+
+[GitHub]:
+  https://github.com
+  "Seite mit sehr vielen Open-Source-Projekten, die git verwenden. Gehört zu Microsoft"
+[GitLab]:
+  https://gitlab.com
+  "Open-Source-Lösung für selbst gehostete Projektverwaltung (git, issue-tracking, …).
+Community (kostenfrei; limitierte features) oder Enterprise-Linzenz"
+[JOSS]: https://joss.theoj.org/ "The Journal of Open Source Software"
+[JORS]:
+  https://openresearchsoftware.metajnl.com/
+  "The Journal of Open Research Software features peer reviewed Software Metapapers describing research software with high reuse potential."
 
 ## Referenz Software {.appendix}
 
@@ -848,16 +875,19 @@ wissenschaftlicher Arbeit.
   javascript im HTML, …) in Bilder gewandelt werden
 - [pandoc][]: DER Konverter für Dokumente. Kann sehr viel in Markdown wandeln
   und hieraus HTML/PDF u.ä. erstellen
+- [pylint][]: Linting-Tool für Python. Formatiert Code und weist auf Probleme
+  (z.b. fehlende Dokumentation) hin.
 - [rst][]: Alternative zu Markdown.
 
-[git]: https://git-scm.com "Versionskontrollsystem"
-[GitHub]:
-  https://github.com
-  "Seite mit sehr vielen Open-Source-Projekten, die git verwenden. Gehört zu Microsoft"
-[GitLab]:
-  https://gitlab.com
-  "Open-Source-Lösung für selbst gehostete Projektverwaltung (git, issue-tracking, …).
-Community (kostenfrei; limitierte features) oder Enterprise-Linzenz"
+[argparse]: ...
+[Sphinx]: ...
+[MkDocs]: ...
+[Doxygen]: ...
+[Roxygen]: ...
+[Javadoc]: ...
+[pdoc]: ...
+[Docstring]: ...
+[git]: https://git-scm.com "Das de-facto Standard-Versionskontrollsystem"
 [graphviz]:
   https://graphviz.org/
   "Textuelle darstellung von Graphen; Standard-Unix-Tool; Auf vielen Systemen verfügbar und rendert zu pdf/svg"
@@ -871,6 +901,10 @@ Community (kostenfrei; limitierte features) oder Enterprise-Linzenz"
   https://pandoc.org/MANUAL.html#pandocs-markdown
   "DER Konverter für Dokumente. Kann sehr viel in Markdown
 wandeln und hieraus HTML/PDF u.ä. erstellen"
+[pylint]:
+  https://www.pylint.org/
+  "Linting-Tool für Python. Formatiert Code und weist auf Probleme (z.b. fehlende Dokumentation)
+  hin."
 [rst]: https://en.wikipedia.org/wiki/ReStructuredText "Alternative zu Markdown."
 
 ## Bibliographie {.appendix}