Hier unter A Sammlung von Mail-Ausschnitte und Auszug Dokumente zu thematischen Fokus unter B Überlegungen zum Vorgehen
Überlegungen Martina (Mail 28-04-2020) Es wäre auch sinnvoll konkret eine Liste an Rezensionen zusammenzutragen, in denen Software für Geisteswissenschaftler bereits besprochen wurde (DE/EN etc., außerhalb der Archäologie kann man sicher fündig werden). Mir ist da so aus dem Ärmel geschüttelt nicht viel geläufig, dass für den "Normalarchäologen" geschrieben ist. Für die Proceedings der CAA in Tübingen (bin ja mal gespannt, wann die fertig werden) habe ich aber etwas verfasst, das eventuell schon in die Richtung gehen könnte. Ist im Anhang.
- Zweck der Software, die getestet wird
- Testumgebung beschreiben (welche Version wurde getestet, welches Betriebssystem)
- Datensatz beschreiben (Was wurde zu Testzwecken verwendet? Wie sehen die Daten aus (nur numerisch, kategorisch, Mischung etc.)?
- Betriebssystem auf dem Software läuft
- Angabe der aktuellsten verfügbaren Version mit Datum
- Grafische Oberfläche oder nur Kommandozeile?
- Bewertung für Qualität der Dokumentation
- Installation (war es leicht oder schwer, gibt es 'Haken', sind Anweisungen ausreichend?)
- Werden technische Details erläutert? (Systemanforderungen, Angaben zu Code und Entwicklungsumgebung, Angaben zu zugrundeliegenden Algorithmen)
- Gibt es eine Bedienungsanleitung? Wie umfangreich ist sie (kurz oder ausführlich mit diversen Beispielen und auch bebilderung)?
- Gibt es weiterführendes Trainingsmaterial (Tutorials)?
- Community: gibt es eine? Ist sie aktiv, hat sie eigene Foren? -> Um weiterführende Hilfe zu bekommen
- Importformate; Welche Datentypen werden unterstützt?
- Exportformate
- Weitere Funktionalitäten
Zu "C" von Timo : Ich weiß nicht, ob das für die ArchInf wichtig ist. Ich meine, am Ende geht es darum, Archäolog*innen, die nicht so viel Ahnung von IT haben, Programme zu empfehlen oder nicht. Ob es für "andere" Fächer interessant ist, spielt für die erst einmal keine so große Rolle. Ich könnte mir da vllt einen Satz zu vorstellen, der darauf hinweist, ob das Programm auch für Kollaborationen mit X,Y,Z geeignet wäre, aber mehr nicht.
die unterschiedlichen Qualitäten finde ich gut 😊Ich befürchte für den „normalen“ Archäologen sind die eher nicht interessant für die in der CAA Community eher schon oder @Sophie @Martina ? Ich denke 1) Kriterien, da 2) nen Score zu berechnen wird sehr schwer, aber sicherlich cool.
ich könnte mir schon vorstellen, dass man diese Kriterien der Softwarequalität mal auf die Archäologie anwendet.
Aber mir stellen sich da folgende Fragen, denn man kann das verschieden aufziehen:
__- Qualität für den Anwender für den die Anwendung initial erstellt wurde
- Qualität für einen Entwickler
- Qualität für mögliche andere Anwender aus verschiedenen Communities__
Das heisst, man kann als Archäologe sagen: "Das Tool ist gut für mich zu benutzen", es kann aber es kann aus den unterschiedlichsten Gründen relativ schwer für Entwickler sein das Tool zu erweiteren oder schwer für andere Communities sein das Projekt mit einer API oder anderen Möglichkeiten anzufragen. Die Frage die ich mir stelle ist: Sind solche Kriterien für Archäologen überhaupt interessant oder nimmt die Archäologie quasi Software "as-is" ohne den Hintergedanken diese weiterzuentwickeln oder weiterentwickeln zu lassen (und ja diese Gedanken kommen ja immer erst wenn man die Software erstmal länger nutzt) Je nach Perspektive werden die Kriterien vermutlich unterschiedlich ausfallen und zutreffen bzw. nicht zutreffen. Geht es uns dabei übrigens um Kriterien oder geht es uns um einen Score der am Ende herauskommen soll? Also eher ein Leitfaden was man beachten könnte oder eine Auszeichnung in Form eines Scores für bereits existierende Lösungen der sich aus den verschiedenen Kriterien aggregiert?
- Zielpublikum: Archäologen mit Interesse an Anwendung von Software
- eher nicht: Entwickler oder technophobe Archäologen
- Analogien zu Rezension von Texten:
- es wird eine Anwendung rezensiert (ein Text)
- es wird geprüft of gewisse Konventionen und Standards eingehalten wurden (Forschungsgeschichte, Forschungsstand)
- es wird angegeben, was die Anwendung kann (inhalt des Textes wird zusammengefasst)
- Was mich an einer Software-Rezension interessieren würde:
- Anwendungsfeld
- Kosten; Nutzungsbedingungen
- Systemanforderungen
- Besonderheiten
- evlt. Alternativen oder auch ähnliche Software
- Was mich vor der Lektüre abschrecken würde
- Software gibt es schon in einer besseren Form
- langer kaum strukturierter Text
- nicht sehr Anwedungsorientiert, fehlender Bezug zur Praxis
- Tabellarische Zusammenfassung für sich wiederholende Kriterien? -> Vergleichbarkeit; Datenbank
- Angabe von Fallbeispielen
- Referenzen auf Anwendungsbeispiele
-
my prerequisites
- my scope of interest reviewing these tools/applications
- background in DH
- background in archaeology
-
Scope of software/application
- which archaeological task serves it
- who are the users in focus
- what are their user stories
-
Usability all over
- how and where do I find the tool (GitLab, Website ...); is this appropriate to the users in focus?
- supports the application or its documentation the user in identifying the scope of the tool?
- is it made clear, which requirements are needed in respect to skills and knowledge?
-
What kind of type: Plugin ? Stand alone ? Webapp ?
- if Plugin: restricted to a certain Browser, Software?
- if Standalone: restricted to an OS, how many realeases, bug reports, Beta Versions etc.
- if WebApp: restricted to a certain Browser, how is the performance (slow?)?
-
License, (single/multi-user)
- what kind of license?
- typical and in accordance with guidelines of scientific ethique?
- if single user, okay with scope of purpose?
-
Import/Export
- if within the purpose of the tool/application: what kind of imports (formats, size, mass-ingest)?
- if within the purpose of the tool/application: what kind of exports (formats, perfromance)?
- any kind of "sharing" and "publishing"? - again in accordance to the scope
-
Documentation
- is there any documentation?
- are there tutorials and information adressing various types of user (newbie, advanced, pro)?
- is this in accordance with the targeted user?
- multinlingual? inclusive?
-
Performance
- own experiences (my own set up)
- if it was not working at all: why and what are lessons to learn?
- if it took a while: why and what have been the solutions in general?
- if it was just great: okay great
- are there any reports or anything else on "stack overflow", "twitter" etc.?
- own experiences (my own set up)
-
Scientific impact
- are there any informations about the use in the community of interest?
- are there any scientific publications towards the application?
- are there any documented use cases?
- do I know someone, who is in the field?
-
Framework
- perhaps just describing it, as not really my area?
- at least it should be stated, if it's unusal?
Einrichtung einer Rezensionsrubrik “Archäoinformatik” in den Archäologischen Informationen?
Stichworte aus der Diskussion
- Rezensionen stets mit konkretem Anwendungsfall verbinden
- Debatte um die Frage der Unabhängigkeit der Rezensenten, inwieweit immer möglich
- überlegen, ob man den Aspekt Archäologie nicht besser in bestehende (internationale) Plattformen einbindet, als etwas eigenes aufzubauen
- These: der Rezensent braucht einen Benefit, z.B. eine Publikation
- es sollte stets ein Bericht eines erfahrenen Nutzers sein, die Kompetenz des Rezensenten muss klar dargestellt werden
- Rezensionen (nach gewisser Zeit) ev. auch als Datenbank ablegen, wg. Suchbarkeit, Durchsuchbarkeit
- Missverständnis „für Archäologie“ sensu: Software explizit für Archäologie (klarstellen, dass gemeint ist: Software, die in der Archäologie eingesetzt wird, nicht nur Software explizit und ausschließlich für die Archäologie gemacht)
- Anregung: besser mehr als 1 Rez. pro Software, weil sich das Ergebnis wohl je nach Anwendungsfall unterscheidet
- Anregung Fl. Thiery: Blick auf die „Research Software Engineer (RSE)“
-
- Knappe Inhaltsangabe: Worum geht es bei der Software?
-
- Welche & wieviel Erfahrungen mit der Software hat der / die Rezensent_in – was ist seine / ihre Perspektive?
-
- Kernfrage: Was ist gut / schlecht an der Software?
-
- Schlussfolgerung: An wen wendet sich das Produkt? Was gäbe es für Alternativen?
-
- Interoperabilität: Lese-Formate, Export-Formate, Betriebssysteme, ...?
-
- Wie ist die Software publiziert?
-
- User Interface, Benutzerfreundlichkeit, Einschätzung der Lernkurve, Erfahrungen mit der Stabilität?
-
- Vollständigkeit und Qualität der Dokumentation? Gibt es Tutorials?
-
- Vorteile / Nachteile im Vergleich zu anderen Softwarelösungen
-
- Ggf. Hinweise auf Archäologie-relevante erfolgreiche Projekte/Anwendungen, die von dieser Software bereits unterstützt wurden.
Terminplan: Ich bin ein Fan von Deadlines und Meilensteinen. Ich würde daher vorschlagen, dass wir uns auch einen Termin setzen. Ich mache einen ersten Vorschlag, der genau das ist, ein Vorschlag. 31. Juli.
Äußerung Martina (Mail 28-04-2020) Plattform: gerne etwas wo ich nicht noch ein weiteres Nutzerkonto anlegen muss (habe Google, GitHub/GitLab, Overleaf), beuge mich aber auch der Mehrheit. Alternativ bietet der Chaos Computer Club Wien ein CryptPad https://pads.c3w.at/ für solche Zwecke an. Wäre eine Weitere Option.
ich fände Variante II.2) auch nicht schlecht. Das scheint mir am "stromlinienförmigsten".
I jups, II finde ich auch gut, könnte man so machen.
I. Ich denke, Timos Fragen A und B haben wir im Griff. C scheint mir etwas zu sein, dass wir durchaus auch im "Leitfaden"/"Kriterienkatalog" diskutieren können. Ich glaube, dass man da erarbeiten kann, was das eigentlich bedeutet und bedeuten kann, Anschlußfähigkeit für andere Disziplinen herzustellen.
II. Zur Einbeziehung weiterer Mitmacher/innen: Ich kann mir drei Szenaien vorstellen, die reizvoll sind, und deren Reihenfolge keine Gewichtung beinhaltet. 1.) Team offen halten und einladen, wer einem dazu einfällt. Und man sammelt in einem offenen Dokument, für das es dann eine Redaktion gibt. 2.) Kernteam von Autor*innen bilden und ersten Draft erzeugen. Dann gezielt zum Review, der Diskussion des ersten Drafts einladen und die Reviews explizit machen und aufnehmen. Dann könnte man den Draft in Zenodo legen und die mit Überarbeitungen und Anmerkungen versehene Version in der DGUF veröffentlichen mit Verweis auf den ersten Draft. 3.) Kernteam bildet sich nach einer offenen Phase bei der man noch Leute findet/sucht und schreibt gemeinsam den Beitrag runter. Der wird (hoffentlich) in der DGUF veröffentlicht und man stellt ihn in weiteren Foren vor. Je nach Rückmeldung veröffentlich man einen Nachtrag/Erweiterung/Kommentar.
III. Schreibumgebung hängt auch ein wenig von II. ab, daher würde ich das aktuell offen lassen, finde aber weitere Meinungsäußerungen hilfreich.