Closed bellerophons-pegasus closed 3 years ago
bellerophons-pegasus
commented
3 years ago Ein Vorschlag von @situx dazu: Wäre vielleicht eine Grafik oder ein Entscheidungsbaum hilfreich? Sowas wie: Was ist mein Background und welche Aspekte sollten hier besonders wichtig sein? Ich denke das kam raus, dass man sich eine Art "Leitfaden für den Leitfaden" wünscht weil die vielen Kriterien die wir aufgeworfen haben doch vll etwas erschlagend wirken.
archaeoklammt
commented
3 years ago Stimme zu, dass die Kritik berechtigt ist und man das aufnehmen sollte. Die Idee eines Entscheidnungsbaums finde ich fortführend, aber denke, wir sollten ihn implizit in den Text einarbeiten. Unter anderem, weil diese Entscheidungsbäume meiner Meinung nach dann doch wieder auf Stereotypen, wie die der "normale" Leserin bzw. des "normalen" Lesers hinauslaufen und diese fortschreiben. Weiterhin finde ich es auch wichtig, dass ein Ergebnis der Lektüre des Impuls zu einer Handreichung sein kann, sich selbst als nicht hinreichend qualifiziert für das Anfertigen einer bestimmten Softwarerezension zu empfinden. Eventuell sollten wir deutlicher machen, dass Rezensionen möglicherweise wesentlich häufiger Teamarbeiten sein werden.
bellerophons-pegasus
commented
3 years ago Das wäre mein Vorschlag, mit Bitte um Feedback:
Die Rezension archäologischer Forschungssoftware setzt die Sichtung von Dokumentation und Publikationen ebenso voraus, wie die praktische Erprobung der Software selbst. Unserem Verständnis nach sollte eine Softwarerezension, so wie es eine herkömmliche Besprechung einer wissenschaftlichen Publikation leistet, die Software zunächst mit zusammenfassenden Eckdaten vorstellen. Anschließend sollte der Kontext erläutert werden und eine kritische Beurteilung erfolgen.
Zu den Eckdaten, welche tabellarisch dargestellt werden können, gehören unter anderem Angaben zur Version, zu den Entwicklern und der Lizenz. Dies ermöglicht z. B. eine schnelle Übersicht darüber, ob die begutachtete Software mit der eigenen technischen Umgebung kompatibel ist. Ein Vorschlag zu den Inhalten einer solchen Tabelle befindet sich am Ende dieses Beitrags.
Mit Kontext ist eine Einordnung in das archäologische Forschungsfeld und Angaben zum möglichen Zusammenhang mit Forschungsprojekten, Arbeitsgruppen oder Institutionen gemeint. Auch der "Kontext" der rezensierenden Person sollte dargestellt werden, denn eine realistische und transparente Einschätzung der eigenen Kompetenzen und des eigenen Nutzungsinteresses stellt einen wichtigen Anhaltspunkt für die heterogene Leserschaft dar. Wurde die Rezension rein aus Sicht eines Anwenders oder auch aus Entwicklersicht geschrieben? Angaben zur verwendeten Testumgebung, also des zum Testen der Software genutzten Computers, können ebenfalls von Bedeutung sein, wie z. B. Angaben zu Betriebssystem, RAM, Prozessor, Grafikkarte oder Bandbreite.
Für die kritische Beurteilung von Forschungssoftware aus verschiedenen Blickwinkeln folgt hier im Anschluss ein in drei Bereiche gegliederter Fragenkatalog. Die Fragen aus dem Bereich "Einsatz in der Archäologie und wissenschaftlicher Zweck" sollten unserer Ansicht nach in jeder Rezension behandelt werden. Als sehr wichtig erachten wir die Beantwortung der Fragen zu Installation, Tutorials, und der tragenden Community, sowie zu Ein- und Ausgabeformaten, Programmierschnittstellen und den Möglichkeiten zur Beteiligung an der Weiterentwicklung der Software.
Allein diese Fragen ziehen weitere nicht unwichtige Folgefragen nach sich. Für die Installation wichtig sind Informationen dazu ob es sich um eine eigenständige (stand-alone) Software oder um eine Webanwendung handelt, ob die Installationsvoraussetzungen klar dokumentiert sind und ob die Dokumentation vollständig und aktuell ist relevant. Im Hinblick auf Tutorials und der tragenden Community stellen sich die Fragen ob eine archäologische Nutzung vorgesehen war, ob es publizierte Anwendungsfälle der Software gibt, ob an der Software aktiv gearbeitet wird und ob Testdatensätze zur Verfügung gestellt werden. Wenn es um Ein- und Ausgabeformate geht, sollte auch gefragt werden wie Daten generell eingelesen werden können. Auch die Bewertung der Bedienungsoberfläche und der Bedienungsmöglichkeiten, sowie die Robustheit der Software sollte unserer Meinung nach nicht fehlen.
Die Ergebnisse der Begutachtung sollten in einer Stellungnahme zusammengefasst werden, welche die Software hinsichtlich ihrer Nützlichkeit, ihrer Bedienbarkeit, ihrer handwerklichen Qualität und ihrer Position in Relation zu den bereits Angesprochenen Idealen guter Forschungssoftware beurteilt.
Der im Anschluss vorgestellte Fragenkatalog ist umfangreich. Somit wird zum Einen aufgezeigt, dass die Entwicklung von Forschungssoftware durchaus als wissenschaftliche Leistung gewertet werden kann. Zum Anderen dient er als Anstoß dazu die eigenen Kompetenzen für die Rezension von Forschungssoftware zu überdenken und die Evaluierung gegebenenfalls in einem Team durchzuführen. Denn so wie Rezensionen von herkömmlichen Publikationen im Idealfall von mit dem Thema betrauten Experten erstellt werden, sollte dies auch für Forschungssoftwarerezensionen gelten.
florianthiery
commented
3 years ago ich find den Teil sehr gut @bellerophons-pegasus :-)
archaeoklammt
commented
3 years ago Liebe Martina, Ich finde es sehr gut !!
Beste Grüße Anne
situx
commented
3 years ago Ich finde den Text auch gut, frage mich aber ob deutlich genug herauskommt, dass die Fragenkataloge als Angebot an die Reviewer verstanden werden diese je nach ihrem Wissensstand zu verwenden. Ich glaube aktuell klingt es noch so als würden wir verschiedene Dinge verschieden gewichten, aber es könnte so verstanden werden, dass ein Reviewer diese trotzdem bearbeiten soll oder sich für die Review ein Team suchen soll. Korrigiert mich wenn ich falsch liege.
archaeoklammt
commented
3 years ago Stimmt vielleicht, am besten konkreten Textvorschlag als Alternative anbieten. Das geht am leichtesten zu verarbeiten.
Deutsches Forum für Kunstgeschichte Paris
Centre allemand d’histoire de l’art Paris
Hôtel Lully
45, rue des Petits Champs
F-75001 Paris
From: Timo [notifications@github.com] Sent: Wednesday, December 09, 2020 6:00 PM To: Research-Squirrel-Engineers/Impuls_SoftwareRezensionen_DGUF Cc: Klammt, Anne; Assign Subject: Re: [Research-Squirrel-Engineers/Impuls_SoftwareRezensionen_DGUF] Abschnitt 'Vorgehensweise' als Anleitung ausarbeiten (#56)
Ich finde den Text auch gut, frage mich aber ob deutlich genug herauskommt, dass die Fragenkataloge als Angebot an die Reviewer verstanden werden diese je nach ihrem Wissensstand zu verwenden. Ich glaube aktuell klingt es noch so als würden wir verschiedene Dinge verschieden gewichten, aber es könnte so verstanden werden, dass ein Reviewer diese trotzdem bearbeiten soll oder sich für die Review ein Team suchen soll. Korrigiert mich wenn ich falsch liege.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttp://mx.dfkg.org:32224/?dmVyPTEuMDAxJiY1OTAwNjU4YzE2MzZmNDE4Mj01RkQxMDJDNV80NDYyOV8xNDkzMF8xJiZiNjdlMWU1MWJlZTAwM2Y9MTIzMiYmdXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViJTJFY29tJTJGUmVzZWFyY2gtU3F1aXJyZWwtRW5naW5lZXJzJTJGSW1wdWxzJTVGU29mdHdhcmVSZXplbnNpb25lbiU1RkRHVUYlMkZpc3N1ZXMlMkY1NiUyM2lzc3VlY29tbWVudC03NDE5MDY4MzQ=, or unsubscribehttp://mx.dfkg.org:32224/?dmVyPTEuMDAxJiY1OTAwNjU4YzE2MzZmNDE4Mj01RkQxMDJDNV80NDYyOV8xNDkzMF8xJiZiNWJlYmUyMTdlOTFiM2Y9MTIzMiYmdXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViJTJFY29tJTJGbm90aWZpY2F0aW9ucyUyRnVuc3Vic2NyaWJlLWF1dGglMkZBTzVVQUNMQlpOSURKM0FOS0lQUkZETFNUNlVNSkFOQ05GU000VFdHWEpXUQ==.
nevrome
commented
3 years ago Ich finde Martinas Text super. Vielleicht könnte man die Priorisierung im Katalog durch eine kleine Markierung hervorheben. z.B. könnte man jedem von uns als essentiell beschiedenen Punkt ein "⚠" oder etwas ähnliches voranstellen. In Lehrbüchern sind solche visuellen Hilfen ja sehr verbreitet. z.B.:
⚠ Welche Datenformate werden wie eingelesen? Sind alle relevanten Datenformate für die Aufgabe, die die Software im typischen Anwendungsfall lösen soll, einlesbar? Werden offene Datenformate unterstützt? Können Datenformate auch von gängigen Repositorien eingelesen werden (z. B. Webservices, Git, Cloud Services)?
Dann würde ich in dem Text oben nach
Als sehr wichtig erachten wir die Beantwortung der Fragen zu Installation, Tutorials, und der tragenden Community, sowie zu Ein- und Ausgabeformaten, Programmierschnittstellen und den Möglichkeiten zur Beteiligung an der Weiterentwicklung der Software.
noch folgendes einfügen:
Diese Punkte sind im Katalogteil mit einem vorangestellten "⚠" markiert.
bellerophons-pegasus
commented
3 years ago Wir könnten sogar etwas abstufen: :bangbang: und :heavy_exclamation_mark:
bellerophons-pegasus
commented
3 years ago Neuer Enwurf. Etwas kürzer.
Die Rezension archäologischer Forschungssoftware setzt die Sichtung von Dokumentation und Publikationen ebenso voraus, wie die praktische Erprobung der Software selbst. Unserem Verständnis nach sollte eine Softwarerezension, so wie es eine herkömmliche Besprechung einer wissenschaftlichen Publikation leistet, die Software zunächst mit zusammenfassenden Eckdaten vorstellen. Anschließend sollte der Kontext erläutert werden und eine kritische Beurteilung erfolgen.
Zu den Eckdaten, welche tabellarisch dargestellt werden können, gehören unter anderem Angaben zur Version, zu den Entwicklern und der Lizenz. Dies ermöglicht z. B. eine schnelle Übersicht darüber, ob die begutachtete Software mit der eigenen technischen Umgebung kompatibel ist. Ein Vorschlag zu den Inhalten einer solchen Tabelle befindet sich am Ende dieses Beitrags.
Mit Kontext ist eine Einordnung in das archäologische Forschungsfeld und Angaben zum möglichen Zusammenhang mit Forschungsprojekten, Arbeitsgruppen oder Institutionen gemeint. Auch der "Kontext" der rezensierenden Person sollte dargestellt werden, denn eine realistische und transparente Einschätzung der eigenen Kompetenzen und des eigenen Nutzungsinteresses stellt einen wichtigen Anhaltspunkt für die heterogene Leserschaft dar. Wurde die Rezension rein aus Sicht eines Anwenders oder auch aus Entwicklersicht geschrieben? Angaben zur verwendeten Testumgebung, also des zum Testen der Software genutzten Computers, können ebenfalls von Bedeutung sein, wie z. B. Angaben zu Betriebssystem, RAM, Prozessor, Grafikkarte oder Bandbreite.
Für die kritische Beurteilung von Forschungssoftware aus verschiedenen Blickwinkeln folgt hier im Anschluss ein in drei Bereiche gegliederter Fragenkatalog. Die Fragen aus dem Bereich "Einsatz in der Archäologie und wissenschaftlicher Zweck" sollten unserer Ansicht nach in jeder Rezension behandelt werden. Als sehr wichtig erachten wir die Beantwortung der Fragen zu Installation, Tutorials, und der tragenden Community, sowie zu Ein- und Ausgabeformaten, Programmierschnittstellen und den Möglichkeiten zur Beteiligung an der Weiterentwicklung der Software. Allein diese Fragen ziehen weitere nicht unwichtige Folgefragen nach sich. Beispielsweise sind für die Installation auch Informationen dazu ob es sich um eine eigenständige (stand-alone) Software oder um eine Webanwendung handelt, ob die Installationsvoraussetzungen klar dokumentiert sind und ob die Dokumentation vollständig und aktuell ist, wichtig. Die unserer Ansicht nach besonders relevanten Fragen sind im Katalog mit einem vorangestellten :bangbang: (sehr wichtig) und :heavy_exclamation_mark: (wichtig) gekennzeichnet.
Die Ergebnisse der Begutachtung sollten in einer Stellungnahme zusammengefasst werden, welche die Software hinsichtlich ihrer Nützlichkeit, ihrer Bedienbarkeit, ihrer handwerklichen Qualität und ihrer Position in Relation zu den bereits Angesprochenen Idealen guter Forschungssoftware beurteilt.
Der im Anschluss vorgestellte Fragenkatalog ist umfangreich und muss auch nicht in allen Einzelheiten abgearbeitet werden. Er zeigt jedoch zum Einen auf, dass die Entwicklung von Forschungssoftware durchaus als wissenschaftliche Leistung gewertet werden kann. Zum Anderen dient er als Anstoß dazu die eigenen Kompetenzen für die Rezension von Forschungssoftware zu überdenken und die Evaluierung gegebenenfalls in einem Team durchzuführen. Denn so wie Rezensionen von herkömmlichen Publikationen im Idealfall von mit dem Thema betrauten Experten erstellt werden, sollte dies auch für Forschungssoftwarerezensionen gelten.
Als Beispiel für die Folgefragen habe ich das Thema 'Installation' genommen, da es an erster Stelle stand. Wenn ihr aber eines der anderen Themen aus dem dann entfernten Absatz (unten zur Referenz reinkopiert) lieber haben wollt, bitte melden. Ich würde aber sagen, dass ein Beispiel reicht, da wir ja sowieso den Fragenkatalog haben.
Allein diese Fragen ziehen weitere nicht unwichtige Folgefragen nach sich. Für die Installation wichtig sind Informationen dazu ob es sich um eine eigenständige (stand-alone) Software oder um eine Webanwendung handelt, ob die Installationsvoraussetzungen klar dokumentiert sind und ob die Dokumentation vollständig und aktuell ist relevant. Im Hinblick auf Tutorials und der tragenden Community stellen sich die Fragen ob eine archäologische Nutzung vorgesehen war, ob es publizierte Anwendungsfälle der Software gibt, ob an der Software aktiv gearbeitet wird und ob Testdatensätze zur Verfügung gestellt werden. Wenn es um Ein- und Ausgabeformate geht, sollte auch gefragt werden wie Daten generell eingelesen werden können. Auch die Bewertung der Bedienungsoberfläche und der Bedienungsmöglichkeiten, sowie die Robustheit der Software sollte unserer Meinung nach nicht fehlen.
nevrome
commented
3 years ago Gefällt mir. Nur ein kleiner, sprachlicher Änderungswunsch:
Statt
Er zeigt jedoch zum Einen auf, dass die Entwicklung von Forschungssoftware durchaus als wissenschaftliche Leistung gewertet werden kann. Zum Anderen dient er als Anstoß dazu die eigenen Kompetenzen für die Rezension von Forschungssoftware zu überdenken und die Evaluierung gegebenenfalls in einem Team durchzuführen.
lieber
Seine Komplexität und Tiefe ist ein guter Indikator dafür, dass die Entwicklung von Forschungssoftware eine vollwertige, wissenschaftliche Tätigkeit sein kann. Wir raten die eigenen Kompetenzen für die Rezension kritisch zu reflektieren und die Evaluierung gegebenenfalls in einem Team durchzuführen.
archaeoklammt
commented
3 years ago 1A
Deutsches Forum für Kunstgeschichte Paris
Centre allemand d’histoire de l’art Paris
Hôtel Lully
45, rue des Petits Champs
F-75001 Paris
From: Clemens Schmid [notifications@github.com] Sent: Thursday, December 17, 2020 2:49 PM To: Research-Squirrel-Engineers/Impuls_SoftwareRezensionen_DGUF Cc: Klammt, Anne; Assign Subject: Re: [Research-Squirrel-Engineers/Impuls_SoftwareRezensionen_DGUF] Abschnitt 'Vorgehensweise' als Anleitung ausarbeiten (#56)
Gefällt mir. Nur ein kleiner, sprachlicher Änderungswunsch:
Statt
Er zeigt jedoch zum Einen auf, dass die Entwicklung von Forschungssoftware durchaus als wissenschaftliche Leistung gewertet werden kann. Zum Anderen dient er als Anstoß dazu die eigenen Kompetenzen für die Rezension von Forschungssoftware zu überdenken und die Evaluierung gegebenenfalls in einem Team durchzuführen.
lieber
Seine Komplexität und Tiefe ist ein guter Indikator dafür, dass die Entwicklung von Forschungssoftware eine vollwertige, wissenschaftliche Tätigkeit sein kann. Wir raten die eigenen Kompetenzen für die Rezension kritisch zu reflektieren und die Evaluierung gegebenenfalls in einem Team durchzuführen.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttp://mx.dfkg.org:32224/?dmVyPTEuMDAxJiYwNzQ2NGVhMGFkMTE4NGM3Nz01RkRCNjFEQl80NDYyOV8xODY5Nl8xJiY1ZDhmNDQ0MThlMjZjZDQ9MTIzMiYmdXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViJTJFY29tJTJGUmVzZWFyY2gtU3F1aXJyZWwtRW5naW5lZXJzJTJGSW1wdWxzJTVGU29mdHdhcmVSZXplbnNpb25lbiU1RkRHVUYlMkZpc3N1ZXMlMkY1NiUyM2lzc3VlY29tbWVudC03NDc0NDk0MTU=, or unsubscribehttp://mx.dfkg.org:32224/?dmVyPTEuMDAxJiYwNzQ2NGU5Y2E3MTY4OGMwNj01RkRCNjFEQl80NDYyOV8xODY5Nl8xJiZlZDhmZDFkMjJmYzc3Y2U9MTIzMiYmdXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViJTJFY29tJTJGbm90aWZpY2F0aW9ucyUyRnVuc3Vic2NyaWJlLWF1dGglMkZBTzVVQUNMTkgyRE9UNVlZUk9YRFQ0TFNWSUQ1VkFOQ05GU000VFdHWEpXUQ==.
SCSchmidt
commented
3 years ago Super!
bellerophons-pegasus
commented
3 years ago gelöst und gepusht
Für den 'Normalrezensenten' könnte unsere Handreichung eine Keule sein, die eher zur Verwirrung beiträgt als dabei hilft eine Rezension von Forschungssoftware zu erstellen.
Die Gutachter dazu: