| title | date | author | |||||||
|---|---|---|---|---|---|---|---|---|---|
Diskussion um den Leitfaden |
2020-06-19 |
|
Archäologen: Was braucht ihr für eine Bewertung von Software?
Hifestellung für Leute, die andere beraten sollen
später auch für andere RSE
neuer Typ Leser durch die Rezensionen?
-
Spagat: Anwendungsfälle beschreiben oder ist der Code wisseschaftlich relevant (algorihtmisch korrekt + algorihtmisch relevant) - die Bewertung des Codes kann kaum jemand leisten, trotzdem als Möglichkeit der Bewertung drinnenlassen (theoretische Vollständigkeit)
- Clemens: Achtung, Leute abschreckend, wenn der Anspruch zu groß ist - Lutz: wissenschaftlich-algorithmisch relevant = Neuzuwachs an Wissen im Bereich der Algorithmen - Martina: das als zusätzliches Kriterim der Bewertung einbauen und nicht als Hauptpunkt? - wird man nicht in allen Rezensionen in allem Detail erfüllen müssen, trotzdem sollte es im Leitfaden abbilden - Forschungssoftware: wichtiger Punkt ist Reproduzierbarkeit, dafür braucht es eine gewisse Bewertung des Codes - nicht alles wird immer für eine Rezension relevant sein (siehe biblatex archaeology) - Idee: gucken, wie Algorithmen getestet wurden, als eine Bewertungsgrundlage-
Hinweis: Wenn einer nicht alles rezensieren kann, die gleiche Software von jemand anderem rezensieren lassen
-
RSE-Definition geht auch in zwei Richtungen: das diskutieren im Leitfaden? (Flo: kommt von Konferenz in Potsdam)
-
-
Begründung: Softwaretools greifen tief in die Forschung ein und müssen deshalb bewertbar werden
-
Auch Anleitung, wie man an eine Rezension ran geht?
-Titeländerung: nicht Leitfaden, sondern "Handreichung" o.ä., so dass klar wird, dass das nicht der Weisheit letzter Schluss ist und klarer wird, dass nicht alle Punkte erfüllt werden müssen ("Kriterien zur Rezension von Forschungssoftware", "Vorschläge / Überlegungen zu Kriterien...", aka "aufposition paper")
- Hoffnung: dass das auch wieder kommentiert wird
nicht ausschließen, dass es mal einen Leitfaden gibt
-
Beispiele für die "unbekannteren" Kriterien geben, damit andere, nicht erfahrene, Leute besser lernen können, was das für Kriterien sind, warum die sinnvoll sind etc
-
nicht festlegen, was nicht in die Rezension rein muss (keine Grenze ziehen), sondern Fragen aufwerfen, die behandelt werden können
-
nicht alle Kriterien müssen beurteilt werden, sondern reicht, dass sie beschrieben werden (teilweise vllt tabellarisch?)
-
Anwendungsfall-abhängige Kriterien aufzeigen, dass es sie gibt
-
gewisse Standards was open standards angeht / FAIR, CARE https://www.gida-global.org/care etc / "pushen" als von uns und DFG etc gewünscht zukünftige Standards
- evtl von den Rezensenten nicht komplett einschätzbar trotzdem wollen wir das gern in den Rezension drin stehen haben
-
Genaue Details, was besprochen wird: den Rezensten die Entscheidungen überlassen?
-
Martina hat einen Gliederungsvorschlag oben eingefügt:
Zielsetzung, Einleitung
Was ist Forschungssoftware was nicht? [Generelle Kriterien und Überlegungen zu Forschungssoftware](#FAIRe Forschungssoftware?) (und auch RSE und Stand von Forschungssoftware in der Fachgemeinschaft; weitere Unterpunkte)
Leitfaden Einleitung und generelle Vorgehensweise Kriterien : -- hier baut Clemens an der Gliederung weiter Bonuskriterien Tabellarische Zusammenfassung?
- Müssen wir wirklich gleich "den Leitfaden" schreiben, oder liefern wir einen Impuls für die Entwicklung eines gemeinsamen Verständnis von Softwarerezensionen in der Archäologie?
- Müssen wir für alles das Definitionen treffen, was aktuell in der Diskussion ist, also:
- was ist Forschungssoftware und was nicht?
- Wer sind die Entwickler*innen und wer ist das nicht?
- oder können wir Bezug auf die Diskussion nehmen und ein Arbeistverständnis für uns beschreiben?
- Sophie stellt dieses Dokument online
- issues daraus bauen
- Clemens und Martina bauen die Gliederung um (issue Gliederung anpassen #2 )
- Feedback an Timo: was irrelevant ist (issue #3) ALLE. damit ein Durchschnitt rauskommt