Siebtes Community-Treffen

==

7. Communitytreffen

==

Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.

Nach drei kurzen Reports aus Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht unter dem Thema:

Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)

• Inhaltliche Dimension - Moderation: Robert Strötgen
• Technische Dimension - Moderation: Jochen Klar

Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.

[toc]

1. Zusammenfassung der Mitschriften

1. 1. Content-Themen

1. 1. 1. Konkrete Bedarfe

- Möglichkeit Felder in DMP mit vorgegebene Informationen zu befüllen, damit die Daten nicht in jedem Projekt neu eingegeben werden müssen. Dafür sollen zwei bis drei Detailgrade der vorgegebenen Felder möglich sein. Eine bereits bestehende Lösung in RDMO, sind die Unterprojekte, die Informationen aus den Eltern-Projekten über die Eltern-Kind-Funktionalität übernehmen. Dies erlaubt es, RDMO mit zwei Detailgraden zu nutzen.

- Zur besseren Übersicht sollten grundlegende Projektinformationen, die bisher meist in den DMP-Fragenkatalogen hinterlegt werden, als Projektmetadaten außerhalb der Fragenkataloge hinterlegt werden können - etwa als Teil der Projektbeschreibung. Dazu gehören Förderer, Projektnummer, beteiligte Institutionen etc.

- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)

- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.

- Einfaches Klonen von Datensätzen / Projekten in RDMO.

- Verbessern der Übersichtlichkeit in der Mandantenversion bei mehr als 20 Katalogen. In RDMO können viele verschiedene Institutionen (= Mandanten) in einer RDMO-Installation zusammen verwaltet werden. Bei vielen unterschiedlichen Fragenkatatlogen pro Mandant ist eine übersichtliche Zuordnung Mandant-Fragenkataloge sinnvoll und erwünscht.

1. 1. 1. Bereits etablierte/s Dienste / Vorgehen

- Wachsendes Portfolio an geteilten Plänen / Vorlagen. - offener Entwicklungsprozess (Open development) - große Auswahl an Optionensätze erleichtern RDMO-Nutznung

1. 1. 1. Community-Beteiligung

- Die Roadmap soll nicht nur technische Aspeckte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz. - Wege am Entwicklungsprozess mitzuwirken besser darstellen: -- Zugang zum Slack ist momentan nur auf Einladung möglich -- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können? -- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren -- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)

1. 1. 1. Lessons learnt

- Content muss laufend gepflegt werden - Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher.

1. 1. Technik / Software

1. 1. 1. Diskussionsgrundlage aus der RDMO-Software-AG

- Es geht in dieser Runde aus Sicht der AG weniger um die Details, dafür ist die Zeit zu knapp, sondern mehr um den Prozess, wie man Entscheidungen fällt und es dann umsetzt. - Anforderungen an den Content sind meist drängender als an die Technik / Software - Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das "wer" ist dann der nächste Schritt.

1. 1. 1. Zusammenfassung des Brainstormings

- Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung? -- Bei Entwicklungen, die von einzelnen Einrichtungen gewünscht werden, werden die Resourcen von den Einrichtungen bereitgestellt. Damit sind momentan auch viele Entscheidungen, was gemacht wird, an einzelne Einrichtungen gebunden. -- Ziel der Community sollte es auch sein, Einrichtungen, die ähnliche interessen / Anforderungen haben zusammenzubringen. Als ersten Schritt wäre eine Übersicht, an was gerade gearbeitet wird oder über welche neuen Funktionen nachgedacht wird hilfreich. -- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen. -- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen. -- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.

- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden

- Ausbau des Entwicklerpools -- Crash-Kurs für Einsteiger in die Entwicklung -- Mehr Informationen zur Plugin-Entwicklung

- Festlegen von Entwicklungsguidelines und -Plänen -- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten -- Workflow für GitHub-Requests -- erhöht Tranparenz der Prozesse

1. 1. 1. 1. Erste Entwicklungswünsche

- Verbessertes User-Interface -- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend) -- graphische IDE für Content-Entwicklung

- "Terms-of-Use" für mehr Authentifizierungsoptionen

- Möglichkeiten zum Vergleich von Kataloginhalten (--> ggf. auch Frage der Content-Bereit- und -Darstellung)

- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability -- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO -- Datenübernahmen ersparten Doppelarbeit -- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür -- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP)

1. Abschluss

Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können? - Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen - Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich. - Idee der Roadmap ist auch folgendes: Eine Einrichtung braucht etwas, hätte auch Geld, aber keine Programmierkenntnisse. Eine andere Einrichtung hätte IT-Praktiker (z.B. SHK) an der Hand.

1. Einzelne Notizen zum RDMO-Treffen Raum 2

1. 1. Technische Dimension

1. 1. 1. Drei Punkte vorneweg für die Diskussion:

- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt. - Content ist meist drängender als Technik - Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert? - Das "wer" ist dann der nächste Schritt.

1. 1. 1. Fragen / Punkte :

- Entscheiden nicht die Institution, die Ressourcen in die Programmierung steckt, was gemacht wird? -- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...) -- Man muss die Einrichtungen zusammenbringen, die ähnliche Interessen haben. Dazu wäre eine Übersicht, wer gerade an was arbeitet oder über eine bestimmte Entwicklung nachdenkt, hilfreich. -- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)

- Modularität von RDMO -- die Plugins sind ein wichtiger Schritt in diese Richtung

- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind -- Das ist prinzipiell über Plugins möglich, aber bis alle FIS ein Austauschformat / eine Austausch-Schnittstelle haben, wird es für viele FIS eigene Plugins brauchen.

- Gibt es Entwicklungs-Guidelines? -- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.

- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.

- Wie ist der Workflow für Requests in GitHub?

- Was sind Roadmaps in anderen Open Source Projekten? -- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.


1. 1. Inhalte - Teil 2

1. 1. 1. Punkte:

- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...) abdecken? -- Das ist sinnvoll und besonders wichtig für die Transparenz.

- Zu Templates von Projekten die schon vorausgefüllt sind: Es gibt schon die (programmatische) Eltern-Kind-Funktion in Projekten. Hier konnen bereits Informationen übernommen werden. Wäre das eine lösung?

- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben -- Basale Informationen (Förderer,...) sollten als "Projektmetadaten" hinterlegt werden, die Fragenkataloge können dann die Daten beschreiben.

- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? -- Stellt Github hier eine Barriere da? -- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? -- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen. -- Die GitHub-Wiki-Funktion könnte auf dem RDMO-GitHub für eine Kommunikation und zum Ablegen von textuell festgehaltenen Ideen (abseits von Issues) genutzt werden. -- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis. -- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten

- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?

- Notsituation "DMP wird schnell benötigt" nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.


1. Einzelne Notizen zu Raum 1

1. 1. Content-Teil

- open development ok:

       Templates für Datenstrukturen 
       Clonen von Datensätzen 

- einfaches Ausfüllen : 2-3 Detaillierungsgrade

       verschiedene Level

- RDMO => generierung von DMP

       =>Organiser Funktionen verbessern
       -> Rechte verteilungen
       -> Nutzerkomfort  verbessern (Anmerkungen?) 

- “Expertenhilfe” organisieren ?

 ‘zuweisen’ von Fragen an Experten ? 

- 20-30 Kataloge bei Mandanten-Version (übersicht) - Statistiken … horizon / DFG template - Sammlung der Kataloge ( )

1. 1. Technik/Software

=> Planung der Entwicklung: - Features List fuer Versionen erwünscht - Release Zeitpunkt machen - Github Issue Votings - oder etwas, das ‘abstraktere’ Features managed - “Projekte” aus Github kostenlos nutzen?

Entwicklungsprozess muss Mittel und Bedarfe matchen

Issues / Features Diskussion evtl. regelmässig organisieren Label für Issues um Prozess/Diskussion transparenter zu machen

=> mehrere Entwickler benötigt: Crash-Course RDMO development? Einführungskurs (JK) evtl. wiederholen Plugin Entwicklung

=> Hereinnahme von anderen Funktionen als DMP Produktion

       Schnittstellen  zu anderen Systemen
       Software management

Projektmanagement ?

=> Beteiligung durch SHK oder andere Ressourcen …..

       Betreuung durch RDMO 
       Content 
       Software Elemente