Reproduktion auf ein konkretes Ergebnis begrenzen
„Die ganze Arbeit reproduzieren“ ist als Auftrag oft zu unbestimmt. Liste die zentralen Tabellen, Abbildungen und Kennzahlen, die das Paket erzeugen soll. Vergib Ergebnis-IDs und verknüpfe sie mit Kapiteln. Definiere, ob eine rechnerische Wiederholung, eine vollständige Rohdatenaufbereitung oder nur ein methodisches Beispiel möglich ist. Diese Grenze gehört in die README.
Unterscheide Reproduzierbarkeit von Replikation. Das Paket soll zunächst zeigen, dass derselbe Analyseweg auf denselben zulässigen Eingaben die dokumentierten Ergebnisse erzeugt. Eine neue Stichprobe und unabhängige Replikation sind eine andere wissenschaftliche Aufgabe. Formuliere keine weitergehende Behauptung, als dein Test belegt.
Eine Ordnerstruktur bildet den Datenweg ab
Die oberste Ebene bleibt kurz: README, Lizenz- und Zitierhinweis, Umgebungsdatei sowie Ordner für Daten, Code, Output und Dokumentation. Rohdaten werden nie durch Skripte überschrieben. Abgeleitete Daten können aus zulässigen Rohdaten neu erzeugt werden. Der Ergebnisordner beginnt leer oder enthält klar bezeichnete Referenzausgaben.
Verwende relative Pfade, damit das Paket nicht an deinen Benutzernamen oder Desktop gebunden ist. Dateinamen zeigen Reihenfolge oder Aufgabe, etwa 01_import, 02_clean und 03_models. Temporäre Dateien, Cache, Betriebssystemreste und Zugangsdaten werden ausgeschlossen. Ein Manifest listet alle enthaltenen Dateien, Rolle und bei wichtigen Eingaben die Prüfsumme.
Die README führt eine fremde Person durch den Start
Beginne mit Zweck, Umfang und erwarteten Ergebnissen. Nenne Voraussetzungen, getestete Softwareversionen und Installationsschritte. Ein einziger Startbefehl oder eine klar nummerierte Klickfolge reduziert Fehlinterpretationen. Beschreibe Laufzeit nur, wenn sie gemessen wurde, und kennzeichne Hardwareabhängigkeit. Erkläre, wo Logs und Ausgaben erscheinen.
Füge eine Datentabelle hinzu: Datei, Herkunft, Version, Lizenz oder Zugang, Schutzklasse und erzeugender Schritt. Erkläre Abkürzungen, fehlende Werte und Einheiten. Nenne bekannte Warnungen und akzeptierte numerische Toleranzen. Kontakt, Autorenschaft, bevorzugte Zitation und Änderungsverlauf runden die Dokumentation ab.
Offenheit endet an Rechten und Schutzpflichten
Entferne personenbezogene und vertrauliche Daten nicht erst aus dem sichtbaren Ordner, sondern prüfe auch Versionsgeschichte, Metadaten, Logs und Zwischenausgaben. Schlüssel, Tokens und lokale Konfiguration gehören nie in das Paket. Bei nicht teilbaren Rohdaten enthält die README eine präzise Beschreibung, Zugangsvoraussetzungen und gegebenenfalls einen kleinen synthetischen Datensatz, mit dem der technische Ablauf getestet werden kann.
Trenne Software-, Daten- und Textlizenzen. Fremde Bibliotheken werden über Abhängigkeitsdateien bezogen, nicht ungeprüft kopiert. Zitiere externe Daten und Code. Prüfe Einwilligung, Ethikauflagen, Verträge und Repositoriumsbedingungen. Bei sensiblen Beständen unterstützt die Seite Anonymisierung und Risikonachweis die Freigabeentscheidung.
Der Clean-room-Test macht aus Dateien ein Paket
Kopiere den Release in einen leeren Ordner oder eine frische virtuelle Umgebung. Folge ausschließlich der README, ohne Wissen aus deinem Arbeitsrechner. Prüfe Installation, Datenpfade und Startbefehl. Der Lauf schreibt neue Ausgaben in output/generated, ohne Referenzdateien zu überschreiben. Vergleiche Ergebnis-IDs, Fallzahlen, Tabellen und Prüfsummen oder dokumentierte Toleranzen.
Lass anschließend eine zweite Person denselben Weg gehen und notiere jede Rückfrage. Korrigiere Anleitung oder Struktur, fixiere eine neue Version und wiederhole den Test. Erfasse Testdatum, Plattform, Ergebnis und verbleibende Abweichungen. Der getestete Release wird anschließend nicht still verändert; Korrekturen erhalten eine neue Versionsnummer.
Abgabe, Archivierung und Zitation verbinden
Erzeuge für den geprüften Stand ein Archiv und ein Manifest. Hinterlege ihn im zulässigen Hochschul- oder Forschungsrepositorium und dokumentiere Zugriffsbedingungen. Verweise aus der Arbeit auf die konkrete Version, nicht auf einen veränderlichen Ordner. Bei Git-Repositorien hilft die Anleitung Release, Commit und Archiv zitieren.
Prüfe zuletzt, ob die Arbeit alle Ergebnis-IDs korrekt verwendet und ob externe Links ohne Anmeldung funktionieren, sofern sie öffentlich sein sollen. Sichere den Abgabestand unabhängig nach deinem Backupplan. Ein Paket ist nicht fertig, wenn es nur auf dem Entwicklungsrechner läuft; es ist fertig, wenn eine fremde Person Umfang, Schutzgrenzen und Ausführung versteht.
Korrekturen nach der Abgabe versioniert veröffentlichen
Zeigt sich später ein Tippfehler, defekter Pfad oder Analysefehler, bleibt der abgegebene Stand erhalten. Dokumentiere das Problem, seine Auswirkung und die Korrektur und erzeuge eine neue Paketversion, sofern Hochschule oder Repositorium dies erlauben. Prüfe den korrigierten Lauf wieder vollständig. Ein neues Versionsdatum, Releasehinweis oder Erratum verhindert, dass der zitierte historische Nachweis still durch andere Dateien ersetzt wird. Erkläre ausdrücklich, ob Tabellen, Argumentation oder Schlussfolgerungen betroffen sind. Kleine technische Korrekturen und inhaltlich relevante Änderungen erhalten dadurch denselben transparenten, aber angemessen detaillierten Nachweis.