Zuerst klären, was der Code belegen soll
Analysecode kann drei verschiedene Aufgaben erfüllen: Er zeigt, wie eine Aussage entstanden ist; er ermöglicht eine technische Wiederholung; oder er dient als nachnutzbares Forschungsprodukt. Ein PDF-Anhang erfüllt vor allem die erste Aufgabe. Ein versioniertes und archiviertes Repositorium kann alle drei unterstützen. Formuliere deshalb vor der Ablage eine konkrete Erwartung: Soll eine Gutachterin einzelne Befehle lesen, das gesamte Ergebnis neu erzeugen oder den Ansatz auf neue Daten übertragen?
Unabhängig vom Ort muss die Arbeit auf den Code verweisen. Nenne Dateiname, Version und relevanten Abschnitt. Ein bloßer URL-Fußnotenlink ohne Erklärung ist anfällig: Ziele können sich ändern, Zugänge können entfallen und die geprüfte Fassung bleibt unklar.
Wann ein Anhang die klarere Lösung ist
Ein Anhang eignet sich für kurze Skripte, die ohne weitere Dateien verständlich sind und dauerhaft zusammen mit der Arbeit archiviert werden. Er ist für Prüfende unmittelbar verfügbar, hat dieselbe Zitierlogik wie der übrige Text und kann exakt nummeriert werden. Besonders nützlich sind kleine Berechnungen, Kodierregeln oder Abfragen, die eine zentrale Tabelle erklären.
Seine Grenze liegt bei Ausführbarkeit und Wartung. Zeilenumbrüche, Silbentrennung und typografische Anführungszeichen können Code beschädigen. Viele hundert Zeilen verdrängen zudem fachlich wichtigere Anhänge. Drucke deshalb nur den Kern ab, verwende eine gut lesbare Monospace-Darstellung und liefere bei Bedarf zusätzlich die echte Textdatei. Der Anhang sollte keine automatisch erzeugten Bibliotheksdateien enthalten.
Was ein Repositorium zusätzlich leistet
Ein Repositorium hält Ordnerstruktur, Versionsgeschichte, Dokumentation, Tests und Umgebungsdateien zusammen. Für die zitierte Fassung sollte ein Release oder Commit feststehen. Ein laufender Hauptzweig allein ist kein stabiler Beleg. Wo möglich, wird der Release in einem Langzeitarchiv mit DOI oder anderer persistenter Kennung gesichert; GitHub selbst erklärt die Zitierdatei, Zenodo die Archivierung von Releases.
Öffentliche Nachnutzung braucht außerdem eine Lizenz. Ohne klare Lizenz ist sichtbarer Code nicht automatisch frei verwendbar. Trenne Softwarelizenz, Datenlizenz und Textlizenz, wenn unterschiedliche Rechte gelten. Eine README nennt Zweck, Voraussetzungen, Startbefehl, Eingaben, erwartete Ausgaben, Autorenschaft und bekannte Grenzen.
Vertraulichkeit vor Bequemlichkeit
Prüfe vor jeder Veröffentlichung nicht nur den aktuellen Code, sondern auch die Versionsgeschichte. Gelöschte Tokens, interne Serveradressen, personenbezogene Pfade und frühere Datendateien können in alten Commits erhalten bleiben. Verwende Testdaten oder synthetische Beispiele, wenn echte Forschungsdaten nicht offen sein dürfen. Konfigurationswerte kommen in eine dokumentierte Beispieldatei; Zugangsdaten werden außerhalb des Repositoriums verwaltet.
Auch Code kann Rückschlüsse auf kleine Gruppen, Erhebungsorte oder Ausschlussentscheidungen erlauben. Bei erhöhtem Risiko kann ein institutionelles Repositorium mit Embargo oder kontrolliertem Zugang angemessen sein. Dokumentiere öffentlich, welche Bestandteile fehlen, warum sie geschützt sind und unter welchen Bedingungen eine Prüfung möglich ist. Diese Seite bietet allgemeine Publikationshilfe, keine Datenschutz- oder Rechtsberatung.
Das Mindestpaket für eine überprüfbare Abgabe
- Fixiere die abgegebene Fassung als Release oder dokumentierten Commit.
- Ordne Skripte nach ihrer Ausführungsreihenfolge und gib einen Startpunkt an.
- Beschreibe Softwareversionen, Pakete und Installation.
- Trenne Rohdaten, Zwischendaten und erzeugte Ergebnisse.
- Füge Lizenz, Zitationshinweis und Kontaktweg hinzu.
- Teste das Paket in einem leeren Ordner und protokolliere die Probe.
In der Arbeit wird nicht die Plattform als Ganzes zitiert, sondern die konkrete Fassung. Ein Eintrag kann Autorinnen, Titel, Jahr, Release, Archiv, DOI oder URL und Zugriffsdatum enthalten – passend zum geforderten Zitierstil. Für Details hilft die Seite GitHub-Repositorien wissenschaftlich zitieren.
Hybrid veröffentlichen ist häufig am stärksten
Die Wahl muss nicht exklusiv sein. Im Anhang kann ein kurzer Schlüsselausschnitt den Argumentationsgang unmittelbar erklären, während das Repositorium das ausführbare Gesamtpaket trägt. Beide Fundstellen nennen dieselbe Releasekennung. Damit bleibt die gedruckte Arbeit verständlich, ohne Code künstlich in Seitenlayout zu pressen. Prüfe zum Abschluss alle Links aus einer nicht angemeldeten Sitzung und archiviere die tatsächlich zitierte Fassung.
Lege zusätzlich ein kleines Manifest mit Dateiname, Zweck und Prüfsumme an. Werden Zusatzdateien separat im Hochschularchiv abgegeben, nenne ihre offiziellen Bezeichnungen im Text und im Ablagevermerk. Eine prüfende Person sollte nie raten müssen, ob „final_neu_2“ oder der aktuelle Hauptzweig die veröffentlichte Ergebnistabelle erzeugt hat. Nach einer Korrektur bleibt die alte Fassung nachvollziehbar; die neue erhält eine neue Versionskennung und eine knappe Änderungsnotiz.
Teste den zitierten Einstiegspunkt nach dem Archivieren erneut. Ein lokaler Hauptzweig kann funktionieren, obwohl im veröffentlichten Release eine Konfigurationsdatei fehlt.