Richtlinien zur Begutachtung von Artefakten

Open Science ist ein wichtiges Thema für die DELFI Community! Dies wird insbesondere sichtbar durch den Arbeitskreis Open Science der Fachgruppe Bildungstechnologien und die seit mehreren Jahren organisierten Open Science Workshops auf der DELFI. In den Einreichungsformaten Kurz-/Langbeiträge sind Artefakte meistens die Grundlage für den präsentierten wissenschaftlichen Beitrag, aber es kann in diesem gegebenen Rahmen nicht die Qualität der Artefakte sichergestellt werden. Ein eigenes Einreichungsformat verschafft der Begutachtung von Artefakten den Raum, um sowohl Artefakte publikationsfähig zu präparieren als auch Gutachter*innen mit dafür geeigneten Fähigkeiten, die sich von der Begutachtung von Kurz-/Langbeiträgen unterscheiden, in den Prozess zur Qualitätssicherung zu involvieren.

Ziel dieses Einreichungsformats ist es, einen Begutachtungsprozess zu erproben und zu etablieren, welcher es ermöglicht, basierend auf vorher definierten Qualitätskriterien, Artefakte zu publizieren. Damit geht einher, dass Autor*innen von Artefakten selbst wählen können, welchen Qualitätskriterien die eingereichten Artefakte gerecht werden können. Der Begutachtungsprozess stellt sicher, dass sowohl die Qualitätskriterien eingehalten wurden als auch dabei unterstützt, diese Qualitätskriterien im gesetzten Zeitraum zu erreichen.

Dies ist die erste Iteration, deswegen bitten wir, als Artifact Chair, um Gelassenheit und Feedback, um den Prozess iterativ verbessern zu können.

• Was ist ein Artefakt?
• Wie läuft die Einreichung von Artefaktbeiträgen ab?
• Ablauf des Reviews
• Anforderungen an die Einreichung
• Bewertung der Artefakte - Erreichbare Badges
• Quellen und weiterführende Literatur

Artefakte sind als Basis wissenschaftlicher Publikationen im Bereich der Bildungstechnologien sehr vielfältig. Dabei können die Artefakte verschiedene Funktionen einnehmen, wie die Dokumentation des Lehr-/Lernszenarios, die Ausführung durch den Betrieb der Technologie sowie die Evaluation durch den Einsatz der Technologie im Lern-/Lehrszenario. Aus diesen unterschiedlichen Funktionen heraus entstehen folgende Typen von Artefakten:

• Software umfasst Skripte, Programme oder Anwendungen, welche sowohl in Form von Source-Code als auch als Software-as-a-Service eingereicht werden können. Software-as-a-Service bezeichnet eine Anwendung, die in einer vordefinierten Umgebung deployed wurde und über eine Webadresse erreichbar und nutzbar ist.
• Daten umfasstDatensätze für Forschung und Lehre, z.B. anonymisierte Lerndaten, Evaluationsergebnisse oder Benchmark-Datensätze.
• Modelle bezieht sich auf trainierte ML-Modelle, welche für den Lern-Lehrkontext trainiert wurden und somit eine eigene Entwicklung darstellt.
• Open Educational Resources (OERs) sind frei zugängliche Bildungsmaterialien wie Lernmodule, Kurse, Tutorials oder Videos unter offenen Lizenzen.
• Andere - Hierfür liegt keine Definition vor, darunter könnte fallen Instrumente/Werkzeuge, Questionnaires, Prompts

In diesem Begutachtungsprozess möchten wir allen Artefakten dieser oben genannten Kategorien die Möglichkeit geben, diese zusätzlich zu veröffentlichen. Wichtig ist zudem die Entscheidung, ob für einen Kurz- oder Langbeitrag ein Artefaktbeitrag oder mehrere Artefaktbeiträge eingereicht werden. Eine strikte Regel, ob Komponenten in einem Artefakt gepackt oder in mehreren Artefakten aufgeteilt werden sollten, lässt sich hierfür nicht formulieren, aber als grobe Richtschnur sollten sich die Autor*innen folgende Frage stellen: Können die einzelnen Artefakte auch eigenständig funktionieren, falls sie auf mehrere Beiträge aufgeteilt werden, ohne dass die anderen Artefakte genutzt werden müssen?

Nach oben

Die Autor*innen aller angenommenen Lang- und Kurzbeiträge werden aufgerufen, Artefakte zur Begutachtung einzureichen. Wenn es zu einem Beitrag mehrere Artefakte gibt (z.B. Software für ein Lernszenario und Daten, die durch die Nutzung der Software erhoben worden) können die Autor*innen frei entscheiden, ob sie alle Artefakte einreichen oder nur eine Auswahl.

Die Einreichung eines Artefakts erfordert zwei Schritte: Im ersten Schritt muss das Artefakt auf einer geeigneten Plattform öffentlich und unter einer persistenten ID zur Verfügung gestellt werden. Dabei ist darauf zu achten, dass das Artefakt alle relevanten rechtlichen Regelungen einhält, insbesondere die DSGVO bei der Bereitstellung von personenbezogenen Daten. Wurde das Artefakt bereits früher veröffentlicht, kann selbstverständlich diese Veröffentlichung genutzt werden und es ist keine erneute Veröffentlichung unter einer neuen ID notwendig. Im zweiten Schritt wird zu jedem Artefakt ein separater Artefaktbeitrag erstellt, der das Artefakt beschreibt und anhand der persistenten ID auf das Artefakt verweist. Weitere Anforderungen und Details zu den beiden Schritten sind weiter unten im Abschnitt “Anforderungen an die Einreichung” angegeben.

Die anschließende Begutachtung überprüft, welche FAIR-Kriterien (Findable, Accessible, Interoperable, Reusable) ein Artefakt erfüllt. Die Erfüllung der Kriterien wird in Form von Badges bescheinigt. Autor*innen können bereits bei der Einreichung angeben, welche Badges sie anstreben. Es ist also insbesondere nicht notwendig, sämtliche FAIR-Kriterien einzuhalten, um trotzdem eine positive Begutachtung zu erhalten. Weitere Details zu den erreichbaren Badges sind weiter unten im Abschnitt “Erreichbare Badges” angegeben.

Nach oben

Die Artefaktbewertung wendet ein single-blind Reviewverfahren mit offener Einreichung an. Folgender Ablauf ist für das Review geplant:

• Das Artefakt wird gemäß der “Anforderungen an die Einreichung” vorbereitet und der Beitrag zur Einreichung vorbereitet. Es ist keine Anonymisierung erforderlich.
• Nach der Einreichung, in der auch das angestrebte Badge ausgewählt werden kann, wird der Gutachtungsprozess angestoßen. Zur Wahl des Badges, siehe “Bewertung der Artefakte - Erreichbare Badges", in dem auch Erfolgskriterien zum Erreichen der Badges definiert sind.
• Gutachter*innen können den Beitrag begutachten und innerhalb der Gutachter*innen in eine Diskussion zum Beitrag gehen.
• Das Review wird an die Autor*innen verschickt mit folgenden Urteilen:
  • Badges erreicht.
  • Kleine Änderungen zum Erreichen der Badges notwendig. Muss nicht erneut gereviewed werden
  • Große Änderungen, welche durch die Reviewer innerhalb kurzer Zeit evaluiert werden können. Badge erreichen noch möglich
  • Große Änderungen notwendig, welche nicht durch den diesjährigen Track zum Erreichen aller Badges führen.
• Einreichung der Camera-Ready Version.
• Alle erreichten Badges werden von den Chairs vergeben.

Der Zeitaufwand pro Artefakt sollte 2 Stunden nicht überschreiten, zuzüglich 30 Minuten für die Überprüfung von großen Änderungswünschen. Darin enthalten sind die Installation des Artefakts sowie alle weiteren Software, die für deren Ausführung erforderlich sind. Übersteigt der Zeitaufwand diesen Grenzwert, sollte sich der Gutachter*innen an die Artefakt-Chairs wenden, die dann über das weitere Vorgehen für das jeweilige Artefakt entscheiden.

Autor*innen sollten zwischen dem Abschluss der Begutachtung und der Vergabe des Badges keine neuen Versionen des Artefakts hochladen.

Modelle können erhebliche Rechenanforderungen haben, die ein einzelner Gutachter*innen nicht erfüllen kann. Gutachter*innen, die das Artefakt nicht ausführen können, kontaktiert die Artefakt-Chairs (nicht die Autor*innen). Die Chairs können eine einmalige Klarstellung zu einem bestimmten Punkt an die Autor*innen weiterleiten, das Artefakt einem Gutachter*innen mit der erforderlichen Infrastruktur neu zuweisen oder – falls die Rechenleistung weiterhin das Hindernis darstellt und in der Veröffentlichung als Mindestanforderung dokumentiert ist – eine verbindliche, fallspezifische Entscheidung treffen.

Nach oben

Die Einreichung für den Artefaktbeitrag umfasst bis zu 4 Seiten und hat den Zweck ein zitierbaren und strukturierten Ist-Zustand des präsentierten Artefakts darzustellen. Der Beitrag zum Artefakt gibt einen Überblick über den Kontext des Artefakts, gibt einen Einstieg zur Nutzung des Artefakts und stellt den zukünftigen Entwicklungsaufwand dar.

Neben dem Beitrag sollen auch die Artefakte so aufbereitet werden, dass diese den Ansprüchen der FAIR-Prinzipien (Daten, Software) gerecht werden. Allgemeine Richtlinien, wie die “barely sufficient practices in scientific computing” oder speziell für Software fair-software.eu.

Falls notwendig, sollte im Artefakt in der README Datei sich zum ethischen Umgang mit den Forschungsdaten verhalten werden (ggf. Statement der Ethikkommission) und eine Stellungnahme zur Einhaltung der Datenschutz-Grundverordnung (DSGVO) verfasst werden.

Einige Pubilkationswege, welche für die Einhaltung der FAIR-Prinzipien notwendig sind, wurden von der DELFI Community noch nicht festgelegt. Die Empfehlungen werden hier kurz umrissen:

• Publikationen aus einem Repository (wie beispielsweise Github oder Gitlab) sollten immer aus einem Release heraus entstehen, sodass der Stand des Artefakts nachvollzogen werden kann.
• Folgende Vorschläge für Archivierungsplattformen, welche zur Publikation der Artefakte verwendet werden können. Für
  • Software: Software Heritage, Zenodo, OSF
  • Data: Zenodo, OSF, figshare, Dataverse, DataShop @CMU  zur Publikation des Artefakts genutzt werden. 
  • Modelle: Zenodo, HuggingFace Hub mit einer stabilen Modellrevision/einem stabilen Commit-Identifikator
  • OERs: OERSI-indexierte Repositorien (z. B. ZOERR, edu-sharing, TwillO, HOOU, vhb), Zenodo

Falls dies nicht möglich ist, sollte dieses im Artefaktbeitrag explizit begründet werden.

• Die Archivierung ist eine Verpflichtung des Autors gegenüber der gewählten Plattform.
• Für Datenpublikationen könnten Datashops, wie beispielsweise, genutzt werden.
• Es sollte eine Lizenz für das Artefakt gewählt werden. Als Empfehlung
  • für Software eine OSI Lizenz 
  • für Daten eine Creative-Commons- (CC) oder Open-Data-Commons (ODC) Lizenz
  • für Modelle Open-Weights-/Responsible-AI-Lizenzen
  • für OERs: Creative-Commons- (CC) Lizenz
• Es sollten Metadaten in einer geeigneten maschinenlesbaren Form im Artefakt im Repositorium des Artefakts vorhanden sein. Beispielsweise könnte das als CFF oder CodeMeta Dateiformat erstellt worden sein. Es wird dazu geraten standardisierte Metadataenformate zu verwenden, bspw. DCAT, schema.org/Dataset, Dublin Core, Frictionless Data, es kann aber keine allgemeine Empfehlung ausgesprochen werden. Speziell für OER könnten folgende Formate genutzt werden: LRMI / schema.org LearningResource, IEEE LOM, OERSI-Metadatenprofil, Dublin Core.
• Die Nutzung von Registries wird empfohlen. Da es noch keine etablierte Registry gibt, sollten die sprachspezifischen Registries genutzt werden, beispielsweise für Pyhon (https://pypi.org), Java (https://central.sonatype.com/), Javascript (https://www.npmjs.com/), C# (https://www.nuget.org/). Für Modelle kann hugging face genutzt werden. Weitere Registries sind hier zu finden: Awesome Research Software Registries
• Wenn ein Repository von einem anderen Standort gespiegelt wird (z. B. eine GitHub-Veröffentlichung, die auf ein Zenodo-Depot gespiegelt wird), ist die Archivierung das kanonische Artefakt für die Begutachtung.
• Immer wenn eine Einreichung ein LLM (geschlossen oder offen) verwendet, muss Folgendes im Artefakt-Papier dokumentiert und zusammen mit dem Artefakt veröffentlicht werden, in Übereinstimmung mit den LLM-Richtlinien:
  • Die Modellkennung und -version (z. B. gpt-4-0125-preview, claude-3-5-sonnet-20241022, meta-llama/Llama-3.1-8B-Instruct).
  • Bei Modellen mit geschlossener Gewichtung: das Datum des verwendeten Modell-Snapshots.
  • Der vollständige Satz an Prompts, einschließlich Systemprompts und aller Promptvorlagen mit aufgelösten Platzhaltern.
  • Alle verwendeten Inferenzparameter (Temperatur, Top-p, maximale Tokenanzahl, Startwert, Stoppsequenzen, Konfiguration der Funktionsaufrufe).

Das Artefakt sollte im Beitrag mit wichtigen Metadaten verlinkt werden. Folgende zusätzlichen Informationen sind im Einreichungsformat möglich:

• Resource Type: Hierbei sollte der Artefakttyp gewählt werden, um den es hauptsächlich geht. Möglichkeiten sind Software, Daten, Modell oder Open Education Resource. Beispielsweise könnten Daten genutzt werden, um die Funktionsweise des eingereichten Softwareprototypen zu demonstrieren, hingegen wird sollte dann Software der hauptsächlich Artefakttyp sein.
• Licence: Die gewählte Lizenz unter der das Artefakt verfügbar ist.
• Stable ID: Der Identifikator des Artefakts ist eindeutig; er verweist auf die spezifische Version eines Artefakts, die sich im Laufe der Zeit nicht ändert; er ermöglicht das Auffinden des Artefakts; und er bleibt über einen ausreichend langen Zeitraum bestehen. Vorzugsweise handelt es sich um einen persistenten Identifikator (z. B. DOI, SWHID).
• Repository (optional): Dieser Eintrag verweist auf die aktuelle Arbeitsumgebung (falls öffentlich), in dem der Arbeitsstand versioniert wurde.

Das angepasste LNI Template sollte für die Einreichung des Artefakts verwendet werden: LNI-Autorenrichtlinien_AET.docx

In Latex kann auch das LNI Template verwendet werde und die Metadaten könnten dann folgendermaßen eingefügt werden:

\begin{abstract}
    Abstract text
\end{abstract}
{\small
\noindent\textbf{Resource Type:} Your text...\\
\noindent\textbf{License:} Your text...\\
\noindent\textbf{Stable ID:} Your text...\\
\noindent\textbf{Repository:} Your text...
\par}
\begin{keywords} Keyword1 \and Keyword2
\end{keywords}

Nach oben

Dieser Abschnitt definiert die verfügbaren Badge und die jeweiligen Kriterien. Das System basiert auf den Definitionen der ACM Artifact Review and Badging, den FAIR-Prinzipien und dem ICSE 2026 Artifact Evaluation Track.

Für die einzelnen Artefakttypen, wie Software, Daten, Modelle, Open Educational Resources(OER)und sonstige Artefakte, wurden die Badges und Kriterien separat definiert.

Die Chairs behalten sich vor, bei der Vergabe von Badges das Recht der finalen Entscheidung ausüben zu können.

• ACM Artifact Review and Badging – Aktuelle Version: https://www.acm.org/publications/policies/artifact-review-and-badging-current
• ICSE 2026 Artifact Evaluation: https://conf.researchr.org/track/icse-2026/icse-2026-artifact-evaluation
• NISO RP-31-2021, Reproduzierbarkeits-Badging und Definitionen: https://groups.niso.org/higherlogic/ws/public/download/24810/RP-31-2021_Reproducibility_Badging_and_Definitions.pdf
• FAIR-Datenprinzipien: https://www.go-fair.org/fair-principles/
• Von der OSI genehmigte Lizenzen: https://opensource.org/licenses
• Creative-Commons-Lizenzen: https://creativecommons.org/share-your-work/cclicenses/
• Open Data Commons-Lizenzen: https://opendatacommons.org/licenses/
• DCAT (Data Catalog Vocabulary): https://www.w3.org/TR/vocab-dcat/
• Frictionless Data: https://frictionlessdata.io/
• DataShop: https://pslcdatashop.web.cmu.edu/
• LLM-Richtlinien: https://llm-guidelines.org/
• HuggingFace Hub: https://huggingface.co/docs/hub/
• Modellkarten für die Modellberichterstattung (Mitchell et al., 2019): https://arxiv.org/abs/1810.03993
• OpenRAIL-Lizenzen: https://www.licenses.ai/
• UNESCO-Empfehlung zu offenen Bildungsressourcen: https://www.unesco.org/en/legal-affairs/recommendation-open-educational-resources-oer
• David Wiley, 5R-Aktivitäten und ALMS-Analyse: https://opencontent.org/definition/
• LRMI / schema.org LearningResource: https://schema.org/LearningResource
• IEEE LOM (Learning Object Metadata): https://standards.ieee.org/ieee/1484.12.1/3637/
• OERSI (Deutscher nationaler OER-Suchindex): https://oersi.org/
• WCAG 2.1: https://www.w3.org/TR/WCAG21/

Nach oben