Achtes Community-Treffen: Unterschied zwischen den Versionen

Aus Forschungsdaten.org
Zur Navigation springen Zur Suche springen
Zeile 211: Zeile 211:


<ul>
<ul>
<li><blockquote><p>Softwareentwicklung</p></blockquote></li>
<li><p>Softwareentwicklung</p></li>
<li><blockquote><p>Nicht-Softwareentwicklung, z.B. Testen, Koordination</p></blockquote></li>
<li><p>Nicht-Softwareentwicklung, z.B. Testen, Koordination</p></li>
<li><blockquote><p>Geld</p></blockquote></li></ul>
<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)

Update Gruppen

Steuerungsgruppe (Harry Enke)

Siehe Folien

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)

Siehe Folien

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)

siehe Folien

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))

Siehe Folien

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)

Siehe Folien

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