Beitragseinreichung

Richtlinien für Autor/innen

Wir laden alle Interessierten ein, ein Tool oder einen Datendienst mit CKIT zu bewerten.

Die Rezension sollte 1500 bis 4000 Wörter umfassen und kann auf Englisch oder Deutsch verfasst werden. Der Text kann Referenzen enthalten, sofern sie die Argumentation der Rezension unterstützen, sowie eine Bibliographie. Beides ist nicht in der Wortzahl inbegriffen. Eine Rezension kann Tests der Software und/oder Testdatensätze enthalten. Solche Datensätze sollten referenziert werden und können auch von CKIT veröffentlicht werden. Falls erforderlich, können Bilder beigefügt werden. Bei den Bildern kann es sich um Screenshots bestimmter Funktionen der grafischen Benutzeroberfläche oder um Flussdiagramme zur Erläuterung der Softwarestruktur handeln. Codeschnipsel sind willkommen und werden wie Textelemente behandelt, aber durch Formatierung hervorgehoben.

Da es sich bei CKIT um eine neue Zeitschrift handelt, befindet sich der Publikationsablauf noch in der Entwicklung. Vorläufig sollten die Beiträge als MarkDown (.md)-Dateien eingereicht werden. Rezensionen werden in Zukunft im PDF- und HTML-Format auf der Website der Zeitschrift verfügbar sein.

Diese Einreichungsrichtlinien sind als Unterstützung für die Autor*innen gedacht. Sie skizzieren die allgemeine Struktur einer Übersichtsarbeit und die wichtigsten Fragen, die behandelt werden sollen. Darüber hinaus geben sie wichtige Aspekte an, die die Autor*innen im Hinblick auf das Interesse der Leser*innen berücksichtigen sollten. Da es für Tools und Datendienste in den Geisteswissenschaften viele Anwendungsfälle gibt und die Forschungspraxis in jedem Bereich unterschiedlich sein kann, steht es den Autor*innen frei, die spezifischen Aspekte zu wählen, die sie hervorheben möchten. Dennoch gibt es bestimmte Aspekte, die notwendigerweise Bestandteil einer jeden Überprüfung sein müssen. Diese sind im Folgenden als "obligatorisch" gekennzeichnet.

Titel / Zusammenfassung / Metadaten (obligatorisch)

• Autor*innen des Tools, Name des Tools, Version, Repository (GitHub etc.) und/oder DOI Autor*innen des Datenservices, Name des Datenservices, URL (Datum des letzten Besuchs)
• Zusammenfassung (in Deutsch und Englisch) des Beitrags, die einen umfassenden Überblick über den Beitrag gibt. Die Länge sollte 130 Wörter für jede Sprache nicht überschreiten.
• Schlüsselwörter/Tags

Konzeptionelle Beschreibung und Bewertung

• Obligatorisch oder dringend empfohlen: Umfang des Tools/Datendienstes: Welche Forschungsfragen unterstützt/adressiert die Software? Welche Art von Forschung oder methodischem Ansatz unterstützt das Instrument oder der Dienst? "Der Datenservice bietet Daten an, die (überwiegend) in der Forschung /wissenschaftlichen Arbeit mit ... verwendet werden. Diese Forschungsfrage, dieser wissenschaftliche Ansatz passt in den Bereich von ..." Damit erhalten die Leser*innen einen vollständigen Überblick über den wissenschaftlichen Anwendungsbereich der Software und können beurteilen, ob die Software oder der Datendienst zu ihrem Forschungsgebiet passt.
• Obligatorisch oder dringend empfohlen: Abstrakte Beschreibung des methodischen Ansatzes: was das Tool macht / was der Datendienst bietet. Die Leser*innen sollten ein klares Bild davon bekommen, wie die Software Daten verarbeitet. Bietet das Tool beispielsweise eine räumliche Interpolation an, sollten die zugrundeliegenden Annahmen und Berechnungen hervorgehoben werden. Manchmal ist dies nicht möglich, da es nicht klar dokumentiert ist - in diesem Fall sollte dies in der Bewertung angegeben werden. Auf der Grundlage dieser Beschreibung sollten die Leser*innen in der Lage sein, zu entscheiden, ob das Tool oder der Dienst ihrem jeweiligen methodischen Ansatz und/oder ihren Anforderungen an die wissenschaftliche Genauigkeit entspricht.
• Empfohlen: Wo immer möglich, sollten frühere Projekte mit einem ähnlichen oder anderen Ansatz auf dem Gebiet oder theoretische Arbeiten zum gleichen Problem erwähnt werden, um die konzeptionelle Arbeit der Entwickler*innen oder des Forschungsteams hinter dem Tool/Datendienst hervorzuheben. Die Leser*innen sollten in der Lage sein, den spezifischen konzeptionellen Ansatz der rezensierten Software in der Forschungslandschaft einzuordnen.
• Empfohlen: Wo immer möglich, sollten Angaben zu Forschungsprojekten oder Institutionen gemacht werden, die das Tool/den Datenservice aktiv nutzen. Dies ermöglicht es den Leser*innen, weitere Anwendungsfälle in Betracht zu ziehen und Informationen über mögliche Ansprechpartner innerhalb der Forschungsgemeinschaft zu erhalten.
• Obligatorisch: Eine ausgewogene und begründete Bewertung des Tools/Datendienstes durch die Verfasser*innen, in der erörtert wird, ob das Konzept des Tools/des Datendienstes für den oben beschriebenen Anwendungsbereich geeignet ist. Da es sich um die Meinung der Gutachter*innen handelt, sollte sie klar als solche gekennzeichnet sein, und die Kompetenzen der Gutachter*innen sollten angegeben werden (es ist nicht erforderlich, dass diese Expert*innen auf dem diskutierten Forschungsgebiet sind, aber eine Vertrautheit mit dem Gebiet ist zwingend erforderlich). Die Aussage muss begründet werden.

Die Sicht der Nutzer*Innen

• Obligatorisch: Wie war die Einrichtung/Testumgebung der Gutachter*innen? Das Verhalten eines Tools kann je nach der technischen Umgebung, in der es läuft, sehr unterschiedlich sein. Bei Webanwendungen können sich verschiedene Browsertypen unterschiedlich verhalten, und native Software kann sich in einer Linux- oder einer Windows-Umgebung unterschiedlich verhalten. Daher trägt eine kurze Beschreibung wie die folgende zur Transparenz der Bewertung bei. "Das Tool wurde in der folgenden Umgebung getestet: MacOS 12, installiert als Homebrew-Paket, Zugriff auf die Schnittstelle über den Chrome-Browser 13.5.1."
• Obligatorisch: Wie wird das Tool oder der Datendienst verwendet? Handelt es sich um eine WebApp? Ist eine Installation erforderlich? Werden mehrere Benutzer*innen unterstützt? Wie lauten die technischen Anforderungen? Da dies für einige Arbeitsumgebungen entscheidende Merkmale sind, müssen sie klar, aber nicht unbedingt ausführlich dargestellt werden. Wenn die Autor*innen überzeugt sind, dass dieser Aspekt ein wichtiger Nachteil ist, sollte dies mit einem Anwendungsfall begründet werden. Bitte beachten Sie, dass Webanwendungen möglicherweise nicht mit jedem Browser funktionieren und dass dies die Benutzerfreundlichkeit in einigen Umgebungen beeinträchtigen kann.
• Empfohlen: Ablauf der Installation, Komplexität, Support. Wenn möglich, sollten die Gutachter*innen die Installation auf verschiedenen Rechnern testen. Der Arbeitsablauf (woher die Software zu beziehen ist, was zu tun ist, wie komplex usw.) sollte in Bezug auf die angenommenen Benutzer*innen und den Umfang der Software dargestellt werden. Wenn die Tester*innen auf eine einzige Umgebung beschränkt sind, sollten vernünftige Annahmen über die Interoperabilität gemacht werden (z. B. "In der Dokumentation steht, dass auch Windows unterstützt wird, ungetestet"). Eine Einschätzung der Zugänglichkeit der Installation kann nur unter Berücksichtigung des Umfangs der Software und der angenommenen Benutzer*innen vorgenommen werden.
• Obligatorisch: Wie funktioniert es - Beschreibung der Hauptmerkmale. Im Gegensatz zur obigen konzeptionellen Beschreibung soll hier ein Eindruck von der Nutzung der Software und der Arbeit mit dem Tool/Datendienst vermittelt werden.
• Obligatorisch: Dateneingabe und -ausgabe - welche Formate (Standards) verarbeitet das Tool/der Datenservice? Massen-Uploads? APIs? Wie sind die Daten mit anderen Ressourcen oder Informationen verbunden? Ist die Verwendung von oder die Verknüpfung mit Normdateien (GND, VIAF, etc.) möglich? Werden kontrollierte Vokabularien verwendet und welche? Da dies für manche Arbeitsumgebungen von entscheidender Bedeutung ist, müssen sie klar, aber nicht unbedingt ausführlich dargestellt werden. Wenn die Gutachter*innen davon überzeugt sind, dass dieser Aspekt einen wichtigen Nachteil darstellt, sollte dies mit einem Anwendungsfall begründet werden.
• Obligatorisch: Unter welcher Lizenz wird die Software veröffentlicht? Gibt es irgendwelche Einschränkungen bei der Nutzung der Software? Wenn es sich um eine Dienstleistung handelt, welche Lizenz wird für die bereitgestellten Daten verwendet? Fallen Kosten an? Welche Institution stellt die langfristige Nutzbarkeit der Software/des Dienstes sicher? Gibt es Finanzierungsquellen? Gibt es eine aktive Community, die die Weiterentwicklung sicherstellt? Dienste und Software müssen langfristig verfügbar sein, um die Reproduzierbarkeit oder die Erklärung von Forschungsergebnissen zu gewährleisten. Daher ist es wichtig abzuschätzen, inwieweit die aktive Pflege und Weiterentwicklung gesichert ist.
• Empfohlen: Benutzeroberfläche - Usability, bei GUIs: Responsive Design. Da die Benutzeroberfläche entscheidend für die Usability ist und ein zu komplexes Design Benutzerfehler begünstigt, ist dies ein wichtiges Merkmal. Eine Abschätzung der Benutzerfreundlichkeit kann nur in Kenntnis des Umfangs der Software und der angenommenen Nutzer*innen vorgenommen werden.
• Empfohlen: Tutorials, Hilfefunktion, Community. Gibt es Tutorials und sind sie für den Zweck geeignet? Gibt es FAQs, Helpdesks etc.? Wie hilfreich sind die Hilfefunktionen und der Support des Tools/Datendienstes ? Sind sie mehrsprachig? Dieser Abschnitt ist besonders hilfreich für die Leser*innen, die Zweifel an den Fähigkeiten ihrer Person oder ihres Teams haben. Eine Einschätzung der Benutzerfreundlichkeit kann nur in Kenntnis des Umfangs und der angenommenen Nutzer*innen vorgenommen werden.
• Empfohlen: Dienstleistungen (Forschungssoftware) Gibt es Einrichtungen, die die Software als Dienstleistung anbieten? Für einige Leser*innen wird dies eine entscheidende Information sein, da sie ein negatives Votum, das nur auf einer möglicherweise zu komplizierten Installation oder zu aufwändigen Anpassung beruht, in ein positives umwandeln kann.

Die Sicht der Entwickler*innen

Dieser Abschnitt, der ausschließlich der Bewertung von Tools gewidmet ist, kann ohne ein fortgeschrittenes Verständnis der Programmierung kaum ausreichend bedient werden. Je nach Zweck des zu prüfenden Objekts wechseln einige Abschnitte und Inhalte zwischen "obligatorisch" und "empfohlen". Darüber hinaus ist z.B. der Begriff des Bauprozesses ausreichend und bedarf keiner weiteren Erläuterung. Das Hauptziel ist es, den Leser*innen Informationen darüber zu geben, wie sie zu der Software/dem Dienst beitragen oder sie/ihn verändern können.

• Obligatorisch: Ist der Code verfügbar?
  Wenn ja, wo wird er gehostet? Wer sind die wichtigsten Mitwirkenden? Wird er aktiv weiterentwickelt? Handelt es sich um eine von der Community betriebene Entwicklung oder um eine institutionelle? Gibt es eine Lizenzvereinbarung für Mitwirkende? Neben den jüngsten Änderungen im Code können auch Pull Requests, Aktivitäten der Entwickler*innen auf Q&A-Websites zum Tool oder persönliche Gespräche auf eine aktive Entwicklung hindeuten.
• Obligatorisch oder dringend empfohlen: Ist die Dokumentation (für Entwickler*innen) verfügbar (obligatorisch) und ist die Dokumentation vollständig und verständlich (empfohlen)? Manchmal, das trifft oft auf eher kleine Tools zu und oder auf Tools, die schon seit längerer Zeit in ständiger Entwicklung sind, ist die Dokumentation als Kommentar im Code zu finden.
• Empfohlen: Ist der Code lesbar (unter Beachtung etablierter Formatierungsstandards), und/oder erweiterbar?
• Empfohlen: Ist die Software getestet (z.B. durch Unit-Tests)?