Achtes Community-Treffen: Unterschied zwischen den Versionen
Zeile 211: | Zeile 211: | ||
<ul> | <ul> | ||
<li | <li><p>Softwareentwicklung</p></li> | ||
<li | <li><p>Nicht-Softwareentwicklung, z.B. Testen, Koordination</p></li> | ||
<li | <li><p>Geld</p></li></ul> | ||
Bitte das MoU unterzeichnen!!! | Bitte das MoU unterzeichnen!!! |
Version vom 15. September 2022, 11:32 Uhr
Agenda and Rollen
- Moderation (Birte Lindstädt)
- Protokoll (Gerald Jagusch & Johannes Frenzel)
TOP 1 Begrüßung
TOP 2 Berichte aus den Gruppen der AG RDMO
TOP 3 Aktuelle Herausforderungen
- Checkliste: Umgang mit den neuen DFG-Vorgaben
- NFDI-DMP-Gruppe (infra-dmp)
TOP 4 Finalisierung Entwicklungs-Roadmap
- Vorstellung der Themencluster (“Github issues”)
- Diskussion und Abstimmung Roadmap
TOP 5 Sonstiges
Angemeldete Teilnehmende
Janna Kienbaum |
Laura Rodríguez |
Katrin Neumann |
Matthias Fingerhuth |
Claas-Thido Pfaff |
Torsten Rathmann |
Kerstin Helbig |
Jochen Klar |
Stephanie Rehwald |
Harry Enke |
Jürgen Rohrwild |
Christoph Sinn |
Vanessa Gabriel |
Raisa Barthauer |
Francesca Schulze |
Denise Jäckel |
Timo Henne |
Max Schröder |
Wahib Sahwan |
Johannes Frenzel |
Christian Langenbach |
Birte Lindstädt |
Martin Spenger |
Juliane Watson |
Fabian Cremer |
Katharina M. E. Grünwald |
Hannes Fuchs |
Hagen Peukert |
Jimena Linares |
Marc Weber |
Sonja Hendriks |
Giacomo Lanza |
Anja Kammel |
Dzulia Terzijska |
Jan Leendertse (RDMG Freiburg) |
Kathrin Höhner |
Katja Diederichs |
Britta Steinke |
Daniela Mertzen |
Fabian Fürste |
Marco Reidelbach |
Thomas Richter |
Kerstin Wedlich-Zachodin |
Sabine Schönau |
Jürgen Windeck |
Gerald Jagusch |
Begrüßung (Gerald Jagusch)
- Rückblick 7. Community Meeting im März: https://www.forschungsdaten.org/index.php/Siebtes_Community-Treffen
- Verschiebung des 8. Meetings vom 13. Juli auf 13. September 2022, Grund dafür waren personelle Engpässe und Ausfälle bei der Vorbereitung des Treffens, insbesondere in der Steuerungsgruppe
Update Gruppen
Steuerungsgruppe (Harry Enke)
V.a. Hinweis auf Wahl der Steuerungsgruppe beim 9. Community Meeting, es scheiden definitiv mehrere der bisherigen Mitglieder aus, KandidatInnen werden also gesucht!
Content-Gruppe inkl. UAGs (Sabine Schönau)
Weitere Teilnahme in den UAGs möglich und sehr erwünscht, nur die UAG Textanleitungen hat ihren Auftrag aktuell fast erfüllt (dies visualisieren die Fortschrittsbalken auf den Folien). Details zu den Gruppen bitte bei den genannten Ansprechpartnern erfragen.
Software-Gruppe (Jochen Klar)
Positive Entwicklung , ca. 10 regelmäßige Teilnehmende in den Gruppenmeetings, inzwischen auch viele Code-Beiträge abseits der Hauptentwickler Jochen Klar und Olaf Michaelis.
Neues weiteres Login-Verfahren (Keycloak), das z.B. Shibboleth und ORCID zugleich ermöglicht;dies ist ein Beitrag von David Wallace von der ULB Darmstadt. Ansonsten viel Bugfixes und Maintenance.
Spanisch als neue Sprache (neben den vier bisherigen: Deutsch, Englisch, Französisch, Italienisch) umgesetzt.
Mehr Transparenz des Entwicklungsprozesses hergestellt durch Überarbeitung der GitHub-Struktur (u.a. Labels und Milestones). Issue-Templates erleichtern das Melden von Bugs und feature requests.
DFG Checkliste:Umgang mit den neuen DFG-Vorgaben (Johannes Frenzel und Kathrin Höhner (UB Dortmund))
DFG ist einer der wichtigster Forschungsförderer in Deutschland, hat nun mit einer FDM-Checkliste die Vorgaben zu FDM-Angaben in Projektanträgen deutlich konkretisiert und verbindlich gemacht. Es ist ein Fließtext als Teil des Antragstexts zu liefern (also innerhalb des Seitenlimits!). Momentan entstehen Ausfüllhilfen abseits von RDMO.
Kathrin HÖhner stellt eine Strategie zum Umgang mit der DFG Checkliste in RDMO vor, die die Erstellung von Textbausteinen beinhaltet, die in einem neuen DFG angepassten Fragenkatalog integriert werden können.
Fragen/Kommentare:
Templates / Fragenkataloge könnten auf DFG-Checkliste angepasst werden, nicht umgekehrt. Das heißt, relevante Fragen können entsprechend getaggt werden.
DFG ist nicht wichtigster Forschungsförderer, BMBF hat größeres Fördervolumen, fordert aber bislang oft keinen DMP.
RDMO ist DFG gefördert, aktuell können die Anforderungen der DFG aber über RDMO nicht erfüllt werden. RDMO sollte als Tool einsetzbar für diesen Zweck, daher Entwicklung von Textbausteinen als ein niedrigschwelliger Zugang. Vorteile sind hier: Insbesondere hilfreich für FDM Beratung, relativ niedriger Aufwand, Forschende werden an RDMO herangeführt.
Wie sieht der Prozess aus? Textbausteine die in Fragen integriert werden können, d.h. neuer Fragenkatalog
Lösung für DFG Anträge in RDMO notwendig. Angebot spezifischerer Fragenkataloge nötig, d.h. DFG Fragenkatalog, danach auch Wechsel zu anderem Template möglich.
Alternative / Ergänzung: neuer an DFG-Anforderungen angepasster “view” als Ausgabe existierender Fragenkataloge
DFG Fragenkatalog würde RDMO einen Schub geben. Grobe Eingabe von Texten bereits möglich. Umsetzung von views möglich, z.B. aus Checkboxen Text generieren. Mehr Funktionalitäten in views möglich (Programmierarbeit).
Stamp / Bildungsforschung: ggf. Vorlage für DFG Anforderungen?
Gibt sich DFG mit vorgefertigten Textbausteinen zufrieden?
Schlechte Erfahrungen mit views an der Uni Wuppertal, da Auffindbarkeit von Textstellen in der Beratungssituation schwierig
Bundesanstalt für Landwirtschaft und Ernährung BLE DMP Fragenkatalog sehr unkonkret (5 Fragen), JKI arbeitet an einem Fragenkatalog, der der BLE vorgeschlagen werden soll. Nutzt ebenfalls RDMO.
Wo wird der Ansatz weiter diskutiert und zeitnah(!) umgesetzt? Contentgruppe, UAG Redaktionsprozesse -> Kontakt Giacomo Lanza (PTB Braunschweig)
Bericht aus der Gruppe NFDI-DMP / infra dmp (Jürgen Windeck)
Beteiligung erwünscht, auch von (noch-nicht)-NFDI-Beteiligten möglich.
Einfach auf die Mailingliste eintragen: https://lists.nfdi.de/postorius/lists/section-infra-wg-dmp.lists.nfdi.de/
Roadmap Prozess: Vorstellung Themencluster (Jochen Klar)
https://docs.google.com/document/d/1AccuTbn3E8OwlbOyLxTR1AswAqlNFzedh-WiEDFduyo/
Aufwand schwierig zu schätzen, kommt auf Erfahrung mit Programmierung von RDMO an. Clusterung in Themen (s. GoogleDoc):
Benutzerfreundlichkeit verbessern, bes. Barrierefreiheit wichtig, da im öffentlichen Bereich notwendig
Projektrollen / -organisation, Zusammenarbeit der user, aufwändig: Versionierung der Antworten und Metadaten zu Projekt erweitern
Ansichten, Schnittstellen
Site management: Nutzungsstatistiken, dashboard, vor allem für Instanzbetreuer
Contentmanagement, Fragenkatalogen erstellen erleichtern: Versionierung von Contentelementen, Modularisierung von Fragen (Fragen nur einmal in Datenbank), konsistente Eingabefenster, mehrmaliges Vorkommen eines Attributes ermöglichen (unter unterschiedlichen Bezeichnungen)
Interoperabilität von Instanzen: Import und Export zw. Instanzen
Multisite
einfachere Betrieb und Pflege der Instanz für Admins
Architektur und Code-Maintenance: Frontend soll umgeschrieben werden, da Komponenten veraltet, ebenso Django framework, korrekte Grammatik für Mehrsprachigkeit notwendig
Roadmap Prozess: Diskussion (und ggf. Abstimmung) Roadmap (Gerald Jagusch)
Fragebogen als Grundlage der Abstimmung https://www.soscisurvey.de/rdmo/
Fragebogen noch bis 18.9.22 offen, 9 Institutionen haben sich bereits beteiligt. Heute kein endgültiges Ergebnis zu erzielen. Auswertung ab nächster Woche durch die Steuerungsgruppe.
Jede Institution sollte einmal den Fragebogen ausfüllen.
Verfügbare Ressourcen angeben:
Softwareentwicklung
Nicht-Softwareentwicklung, z.B. Testen, Koordination
Geld
Bitte das MoU unterzeichnen!!!
Auf Github kann auch über issues diskutiert werden/Anmerkungen gemacht werden.
Fragen / Kommentare:
Gibt es tutorials um den Einstieg in die Programmierung von RDMO zu erleichtern? z.B. Unterschied RDMO und RDMO App? Gibt es teilweise, z.B. Dokumentation / readthedocs.io; Jochen Klar bietet an seine Entwicklungsstrategie in der Softwaregruppe zu präsentieren.
Details zu den issues diskutieren? Priorisierungen ok? Es werden die Themencluser einzeln in der Diskussion betrachtet.
Barrierefreiheit: aus Themencluster rausnehmen? Sehr hoher Aufwand bei relativ niedrigen output? Gibt es einen Mehrwert für die Nutzenden?
Erfahrungen: Fulda: Forderung des PR als Voraussetzung zur Installation, kritisch: Tastatursteuerung umsetzen als minimale Anforderung
Müsste in mehrere issues aufgegliedert werden
Es gibt Erfahrungen, dass PRs zustimmen, wenn Grundfunktionalitäten vorhanden sind
An der HU Berlin wäre ein Produktivbetrieb nur mit Barrierefreiheit möglich. Sie sind aber noch nicht mal beim Demobetrieb und würden das Thema erst mittelfristig angehen
Formale Anforderung vs nicht unbedingt notwendig
“Koordination der Willigen”/derjenigen, die es unbedingt benötigen? Haben diese Institutionen Ressourcen dafür?
Betrifft auch weitere issues, die kontrovers gesehen werden, z.B. Multisite Installation (UB Darmstadt),
Feste Projektinformationen hinterlegen: formelle Informationen fixen, um mehrfaches Antworten zu vermeiden; nur als optionale Felder sinnvoll
Inhaltlich können issues zusammenhängen, sodass sich eine gemeinsame Implementierung anbietet. Bei ähnlichen Fällen in Roadmap berücksichtigen, z.B. Cluster 5 Content-Management in der Instanz / Erstellung von Fragenkatalogen
Versionierung von Content-Elementen, #158, ****
Modularisierung Fragensets, Fragen, Optionen, #450, ****
Vereinheitlichtes Interface zum Editieren von allen Elementen, ****
Wichtige Basis für viele weitere Issues: Modernisierung Front-end, #518, **** (Cluster Architektur und Code-Maintenance,
Diskussion zu Mitarbeit und Finanzierung
Einschätzung der Aufwände / Umrechnung in Geld:
*-Stern: Kleinigkeiten, die eher aus der Community kommen sollten, zu klein für Auftragsvergabe
**-Stern: 1 Tag Entwicklungsaufwand (z.B. Jochen Klar)
***-Stern-issues: ca. 3-5 Tage Entwickungsaufwand (z.B. Jochen Klar)
****-Sterne: muss man individuell beurteilen
Idee: weiteren kommerziellen Dienstleister für RDMO-Entwicklungen finden (neben Jochen Klar), dafür muss das mögliche Finanzvolumen eruiert werden, um dann gezielt auf Firmen zugehen zu können (Aufgabe für die RDMO-Steuerungsgruppe!?), konkretes Bündeln ist schwierig, aber (letztlich unverbindliche!) Koordination ist möglich
Release management muss und soll in der Hoheit der RDMO-AG bleiben
Bei HU Ausschreibung für RDMO lagen die Preise zwischen 45€ und 110€ pro Entwicklungsstunde
Projekt/Releasemanagement ist weiter zu überdenken, momentan macht es Jochen; insb. wenn RDMO größer wird, muss die SG insg. mehr Verantwortung übernehmen
J. Watson: Vielleicht wäre es ja sinnvoll, diese tolle Issue-Liste dann mit dem tatsächlichen Aufwand abzugleichen, also auch von externen contributors... am Ende bleibt die Schätzung immer etwas grob, das finde ich ok. In den Aufwand sollte m.E. aber auch die Arbeit an / mit der Steuerungsgruppe/Softwaregruppe einkalkuliert werden.
Wie geht es weiter?
Befragung auswerten
Konsultation Steuerungsgruppe, auch mit Software-Gruppe
Roadmap erstellen mit gezielten Ansprachen von Institutionen
Teambildung für das Bearbeiten einzelner hoch-gerankter issues
Nächstes Community Treffen Anfang 2023, Neuwahl der Mitglieder der Steuerungsgruppe
Sonstiges
Neues Geld von der DFG einwerben, um RDMO an die (neuen) Anforderungen der DFG anzupassen?
DFG-VIGO Programm: Anschubfinanzierung für Community- / Verbundprojekte für 2 Jahre (50% E13 Stelle), AG RDMO ist dafür ggf. schon zu weit entwickelt
DFG-LIS-Antrag: Umfang erweitern, wichtige Weiterentwicklungen beantragen
Vorgespräch mit DFG?
Base4NFDI als mögliche künftige Geldquelle?
Finanzierung von Weiterentwicklungen ist da fraglich, da geht es eher um Verbreitung und breiten Betrieb von RDMO und inhaltliche DMP-Punkte