<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de">
	<id>https://www.forschungsdaten.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Harry</id>
	<title>Forschungsdaten.org - Benutzerbeiträge [de]</title>
	<link rel="self" type="application/atom+xml" href="https://www.forschungsdaten.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Harry"/>
	<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php/Spezial:Beitr%C3%A4ge/Harry"/>
	<updated>2026-05-19T03:35:24Z</updated>
	<subtitle>Benutzerbeiträge</subtitle>
	<generator>MediaWiki 1.43.8</generator>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6951</id>
		<title>RDMO</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6951"/>
		<updated>2022-03-24T13:45:15Z</updated>

		<summary type="html">&lt;p&gt;Harry: adjust Open Source project status&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Projekt&lt;br /&gt;
|VollständigerName= Research Data Management Organiser&lt;br /&gt;
|ZeitraumVon= 01.11.2017&lt;br /&gt;
|ZeitraumBis= 30.04.2020&lt;br /&gt;
|Beteiligt=RDMO Arbeitsgemeinschaft&lt;br /&gt;
|Förderung= DFG bis 2020 (AIP, FH Potsdam, KIT),&lt;br /&gt;
RDMO Arbeitsgemeinschaft ab 2020&lt;br /&gt;
|Website=http://rdmorganiser.github.io/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Der Research Data Management Organiser, kurz RDMO, ist ein Tool zur Erstellung von Datenmanagementplänen. Es wurde im Rahmen eines DFG-geförderten Projekts entwickelt und nun von einer RDMO-Arbeitsgemeinschaft weiter betreut, in der jeder mitarbeiten kann.&lt;br /&gt;
&lt;br /&gt;
=Einleitung=&lt;br /&gt;
Ziel des Projekts ist es, ein Werkzeug zur Verfügung zu stellen, das die strukturierte Planung, Umsetzung und Verwaltung des Forschungsdatenmanagements unterstützt und zusätzlich die textuelle Ausgabe eines Datenmanagementplans (DMP) ermöglicht. Ein Datenmanagementplan soll klären auf welche Art und Weise mit den anfallenden Forschungsdaten während, aber auch nach dem Ende eines Projekts, umgegangen werden soll. Es gilt beispielsweise zu klären in welchem Umfang Forschungsdaten anfallen, wie und wo diese gespeichert werden sollen und wer darauf zugreifen darf. Wie unter [[Data_Management_Pläne]] erklärt, gibt es bereits von verschiedenen Institutionen entwickelte Online-Tools: das Digital Curation Centre (DCC) in Großbritannien mit [http://dmponline.dcc.ac.uk DMPonline], die California Digital Library (CDL) mit dem [http://dmptool.org DMPTool] und in Deutschland das [http://data.uni-bielefeld.de/de/data-management-plan Online Tool für die Erstellung eines DMP] der Universität Bielefeld.&lt;br /&gt;
&lt;br /&gt;
=Geschichte/Entwicklung=&lt;br /&gt;
&lt;br /&gt;
==Erste Projektphase==&lt;br /&gt;
&lt;br /&gt;
Die erste Projektphase dauerte von November 2015 bis April 2017 und diente der Entwicklung von RDMO. &lt;br /&gt;
&lt;br /&gt;
Der Hauptzweck von Tools zur Erstellung von DMPs ist es, den Vorgaben des jeweiligen Förderers zu entsprechen und die einmalige Erstellung eines DMPs zu unterstützen. Das Ziel von RDMO ist jedoch eine Nutzung, die über die Antragsstellung hinausgeht. So kann das Erstellen eines DMPs die Planung des Forschungsdatenmanagements im Vorfeld optimieren und der Datenmanagementplan schließlich das ganze Projekt lang begleiten und unterstützen, in dem er als Leitfaden dient. Dies könnte die Effizienz und die Qualität der wissenschaftlichen Arbeit erhöhen und somit auch die Motivation der Forschenden solch einen DMP zu erstellen. Die Zielgruppe sind jedoch nicht nur die Forschende selbst, sondern auch alle im Forschungsdatenmanagement Involvierten. Das Tool ist für die verschiedensten Disziplinen und Institute anpassbar und einsetzbar. Das Online-Tool wird derzeit auf Deutsch und Englisch angeboten.&lt;br /&gt;
&lt;br /&gt;
==Zweite Projektphase==&lt;br /&gt;
&lt;br /&gt;
Das RDMO-Projekt befindet sich derzeit in der zweiten Pojektphase, die von November 2017 bis April 2020 läuft.&lt;br /&gt;
&lt;br /&gt;
Die Ziele für die zweite Projektphase sind insbesondere:&lt;br /&gt;
&lt;br /&gt;
*Erweiterung des Organisers: Rollenkonzept, Kostenabschätzung, Ingest-Prozess, Interoperabilität&lt;br /&gt;
&lt;br /&gt;
*Integration in die Infrastruktur: standardisierte Installation, Wartbarkeit, Ausbau der untersützten Authentifizierungs- und Autorisierungs-Systeme&lt;br /&gt;
&lt;br /&gt;
*Etablierung in der Community&lt;br /&gt;
&lt;br /&gt;
*Nachhaltigkeit / Verstetigung&lt;br /&gt;
&lt;br /&gt;
==RDMO Arbeitsgemeinschaft==&lt;br /&gt;
&lt;br /&gt;
Mit der Verabschiedung eines Memorandum of Understanding (MoU) wird das RDMO Projekt durch die RDMO Arbeitsgemeinschaft weitergeführt. &lt;br /&gt;
&lt;br /&gt;
Die RDMO Arbeitsgemeinschaft hat drei Arbeitsgruppen gebildet: Steuerungsgruppe , Softwaregruppe, Contentgruppe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Berichte==&lt;br /&gt;
&lt;br /&gt;
[[Erstes Community-Treffen|1. Community-Treffen]] (Essen, September 2018)&lt;br /&gt;
&lt;br /&gt;
[[Zweites Community-Treffen|2. Community-Treffen]] (Darmstadt, Oktober 2019)&lt;br /&gt;
&lt;br /&gt;
[[Drittes Community-Treffen|3. Community Treffen]] (Potsdam, Februar 2020)&lt;br /&gt;
&lt;br /&gt;
[[Viertes Community-Treffen|4. Community Treffen]] (Virtuell, Oktober 2020)&lt;br /&gt;
&lt;br /&gt;
[https://rdmorganiser.github.io/rdmo_arge/ MoU und RDMO Arbeitsgemeinschaft] (Virtuell, Februar 2021)&lt;br /&gt;
&lt;br /&gt;
[[Sechstes Community-Treffen|6. Community Treffen]] (Virtuell, Oktober 2021)&lt;br /&gt;
&lt;br /&gt;
[[Siebtes Community-Treffen|7. Community Treffen]] (Virtuell, März 2022)&lt;br /&gt;
&lt;br /&gt;
=Anleitungen=&lt;br /&gt;
&lt;br /&gt;
==Dokumentation==&lt;br /&gt;
&lt;br /&gt;
Die Dokumentation für die Installation und die Einrichtung von RDMO ist unter [http://rdmo.readthedocs.io/de/latest] zu finden.&lt;br /&gt;
&lt;br /&gt;
==Tutorials==&lt;br /&gt;
&amp;lt;span id=&amp;quot;RDMOTutorials&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;&lt;br /&gt;
Tutorials für RDMO sind auf der RDMO-Webseite unter [[https://rdmorganiser.github.io/tutorials/ Tutorials]] verlinkt, wir versuchen auch untenstehende Übersicht aktuell zu halten:&lt;br /&gt;
&lt;br /&gt;
*Schnellstart-Anleitung für Nutzer [[https://rdmorganiser.github.io/docs/Schnellstartanleitung.pdf PDF]]&lt;br /&gt;
*Schnellstart-Anleitung für Administratoren [[https://rdmorganiser.github.io/docs/SchnellstartanleitungAdminsv2.pdf PDF]]&lt;br /&gt;
*[[Katalog_erstellen|&amp;quot;Wie erstelle ich einen Fragenkatalog in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Ansicht_erstellen|&amp;quot;Wie erstelle ich eine Ansicht (View) in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Bedingung_erstellen|&amp;quot;Wie erstelle ich eine Bedingung in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Import_Export|&amp;quot;Wie importiere und exportiere ich XML-Dateien in RDMO?&amp;quot;]]&lt;br /&gt;
&lt;br /&gt;
==Frequently asked questions (FAQ)==&lt;br /&gt;
&lt;br /&gt;
[[RDMO_FAQ|Frequently asked questions]]&lt;br /&gt;
&lt;br /&gt;
==Verfügbares und in Vorbereitung befindliches Zubehör in der RDMO-Community==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!Institution&lt;br /&gt;
!Produkt, z.B. Fragenkatalog&lt;br /&gt;
!vor allem geeignet für&lt;br /&gt;
&lt;br /&gt;
!Benennung&amp;lt;br /&amp;gt;&lt;br /&gt;
!Ansprechpartner&lt;br /&gt;
!Status mit Link, falls verfügbar&lt;br /&gt;
!Beschreibung&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne (DMP) allgemein&lt;br /&gt;
|RDMO&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|generisch, detailliert&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Schweizer Nationalfonds&lt;br /&gt;
|SNF&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|Kurzer Fragenkatalog&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|Kurzversion des RDMO-Katalogs&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|DCC Checkliste 4.0&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|entwickelt nach DCC. (2013). Checklist for a Data Management Plan. v.4.0. Edinburgh: Digital Curation&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Ansicht&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG, 1. Version des DMP&lt;br /&gt;
|DFG&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten.pdf DFG-Leitlinien zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 101 Alte Kulturen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_101_forschungsdaten.pdf Handreichung zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Projekte mit mündlichen Korpora, 1. Version des DMP&lt;br /&gt;
|DFG 104 Mündlicher Korpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Textkorpora-Projekte, 1. Version des DMP&lt;br /&gt;
|DFG 104 Textkorpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 105 &amp;quot;Literaturwissenschaft&amp;quot;, Editionsprojekte, 1. Version des DMP&lt;br /&gt;
|DFG 105 Edition&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf Förderkriterien für wissenschaftliche Editionen in der Literaturwissenschaft]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 106, 1. Version des DMP&lt;br /&gt;
|DFG 106 Sozial- u. Kulturanthropologie, Außereurop. Kulturen, Judaistik u. Religionswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_106_forschungsdaten.pdf Handreichung des Fachkollegiums 106 Sozial- und Kulturanthropologie, Außereuropäische Kulturen, Judaistik und Religionswissenschaft zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 109 &amp;quot;Erziehungswissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 109 Bildungswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Petra Stanat, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_bildungsforschung.pdf Bereitstellung und Nutzung quantitativer Forschungsdaten in der Bildungsforschung: Memorandum des Fachkollegiums &amp;quot;Erziehungswissenschaft&amp;quot; der DFG]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 110 &amp;quot;Sozialwissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 110 Sozialwiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 111 &amp;quot;Wirtschaftswissenschaften&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 111 Wirtschaftswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement] und [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/fachkollegium112_forschungsdatenmanagement_de_1811.pdf Management von Forschungsdaten: Was erwartet das Fachkollegium 112 &amp;quot;Wirtschaftswissenschaften&amp;quot; von Antragstellenden?]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Projekte in der Biodiversitätsforschung&lt;br /&gt;
|DFG Biodiversitätsforschung&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_biodiversitaetsforschung.pdf Richtlinien zum Umgang mit Forschungsdaten in der Biodiversitätsforschung]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne allgemein&lt;br /&gt;
|Alle Fragen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|RDMO-Katalog erweitert um die Fragen in den anderen FoDaKo-Katalogen&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Unterstützung bei Beratungsgesprächen&lt;br /&gt;
|UA Ruhr-Beratung&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann vor einem Beratungsgespräch zu Datenmanagementplänen oder FDM allgemein ausgefüllt werden, als Grundlage für das Gespräch.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Antragstellung&lt;br /&gt;
|UA Ruhr-Antrag&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden um das Datenmanagement für einen Antrag dokumentieren zu können.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Zur Beantragung von Speicherplatz&lt;br /&gt;
|UA Ruhr-Archiv&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden, wenn geplant ist die Daten in einem zentralen Speicher, Archiv oder Repositorium abzulegen.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Forschungsdatenmanagement allgemein&lt;br /&gt;
|UA Ruhr&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|In diesem Katalog sind alle UARuhr-Fragen enthalten. Er behandelt umfassend die verschiedenen Aspekte des Forschungsdatenmanagements, deckt Anforderungen verschiedener Disziplinen ab, und ist daher recht umfangreich.&lt;br /&gt;
|-&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Weblinks==&lt;br /&gt;
&lt;br /&gt;
*RDMO-Projektwebseite: http://rdmorganiser.github.io/&lt;br /&gt;
*RDMO-GitHub Organisation und Quellcode: http://github.com/rdmorganiser&lt;br /&gt;
*RDMO-Demo-Instanz: http://rdmo.aip.de&lt;br /&gt;
&lt;br /&gt;
[[Kategorie:Projekte]]&lt;br /&gt;
[[Kategorie:Data Management]]&lt;br /&gt;
[[Kategorie:Open Science]]&lt;br /&gt;
[[Kategorie:Förderorganisationen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Communitytreffen&amp;diff=6950</id>
		<title>Siebtes Communitytreffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Communitytreffen&amp;diff=6950"/>
		<updated>2022-03-24T13:41:04Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite Siebtes Communitytreffen nach Siebtes Community-Treffen&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#WEITERLEITUNG [[Siebtes Community-Treffen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6949</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6949"/>
		<updated>2022-03-24T13:41:04Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite Siebtes Communitytreffen nach Siebtes Community-Treffen&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Notizen zum RDMO-Treffen Breakout-Raum 2====&lt;br /&gt;
&lt;br /&gt;
=====Technik / Software=====&lt;br /&gt;
&lt;br /&gt;
*[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu RDMO Breakout-Raum 1====&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
- open development ok:[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|rahmenlos|600x600px|rechts]]&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6948</id>
		<title>RDMO</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6948"/>
		<updated>2022-03-24T13:40:24Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Berichte */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Projekt&lt;br /&gt;
|VollständigerName= Research Data Management Organiser&lt;br /&gt;
|ZeitraumVon= 01.11.2017&lt;br /&gt;
|ZeitraumBis= 30.04.2020&lt;br /&gt;
|Beteiligt=AIP, FH Potsdam, KIT&lt;br /&gt;
|Förderung= DFG bis 2020,  RDMO Arbeitsgemeinschaft ab 2020&lt;br /&gt;
|Website=http://rdmorganiser.github.io/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Der Research Data Management Organiser, kurz RDMO, ist ein Tool zur Erstellung von Datenmanagementplänen. Es wurde im Rahmen eines DFG-geförderten Projekts entwickelt und nun von einer RDMO-Arbeitsgemeinschaft weiter betreut, in der jeder mitarbeiten kann.&lt;br /&gt;
&lt;br /&gt;
=Einleitung=&lt;br /&gt;
Ziel des Projekts ist es, ein Werkzeug zur Verfügung zu stellen, das die strukturierte Planung, Umsetzung und Verwaltung des Forschungsdatenmanagements unterstützt und zusätzlich die textuelle Ausgabe eines Datenmanagementplans (DMP) ermöglicht. Ein Datenmanagementplan soll klären auf welche Art und Weise mit den anfallenden Forschungsdaten während, aber auch nach dem Ende eines Projekts, umgegangen werden soll. Es gilt beispielsweise zu klären in welchem Umfang Forschungsdaten anfallen, wie und wo diese gespeichert werden sollen und wer darauf zugreifen darf. Wie unter [[Data_Management_Pläne]] erklärt, gibt es bereits von verschiedenen Institutionen entwickelte Online-Tools: das Digital Curation Centre (DCC) in Großbritannien mit [http://dmponline.dcc.ac.uk DMPonline], die California Digital Library (CDL) mit dem [http://dmptool.org DMPTool] und in Deutschland das [http://data.uni-bielefeld.de/de/data-management-plan Online Tool für die Erstellung eines DMP] der Universität Bielefeld.&lt;br /&gt;
&lt;br /&gt;
=Geschichte/Entwicklung=&lt;br /&gt;
&lt;br /&gt;
==Erste Projektphase==&lt;br /&gt;
&lt;br /&gt;
Die erste Projektphase dauerte von November 2015 bis April 2017 und diente der Entwicklung von RDMO. &lt;br /&gt;
&lt;br /&gt;
Der Hauptzweck von Tools zur Erstellung von DMPs ist es, den Vorgaben des jeweiligen Förderers zu entsprechen und die einmalige Erstellung eines DMPs zu unterstützen. Das Ziel von RDMO ist jedoch eine Nutzung, die über die Antragsstellung hinausgeht. So kann das Erstellen eines DMPs die Planung des Forschungsdatenmanagements im Vorfeld optimieren und der Datenmanagementplan schließlich das ganze Projekt lang begleiten und unterstützen, in dem er als Leitfaden dient. Dies könnte die Effizienz und die Qualität der wissenschaftlichen Arbeit erhöhen und somit auch die Motivation der Forschenden solch einen DMP zu erstellen. Die Zielgruppe sind jedoch nicht nur die Forschende selbst, sondern auch alle im Forschungsdatenmanagement Involvierten. Das Tool ist für die verschiedensten Disziplinen und Institute anpassbar und einsetzbar. Das Online-Tool wird derzeit auf Deutsch und Englisch angeboten.&lt;br /&gt;
&lt;br /&gt;
==Zweite Projektphase==&lt;br /&gt;
&lt;br /&gt;
Das RDMO-Projekt befindet sich derzeit in der zweiten Pojektphase, die von November 2017 bis April 2020 läuft.&lt;br /&gt;
&lt;br /&gt;
Die Ziele für die zweite Projektphase sind insbesondere:&lt;br /&gt;
&lt;br /&gt;
*Erweiterung des Organisers: Rollenkonzept, Kostenabschätzung, Ingest-Prozess, Interoperabilität&lt;br /&gt;
&lt;br /&gt;
*Integration in die Infrastruktur: standardisierte Installation, Wartbarkeit, Ausbau der untersützten Authentifizierungs- und Autorisierungs-Systeme&lt;br /&gt;
&lt;br /&gt;
*Etablierung in der Community&lt;br /&gt;
&lt;br /&gt;
*Nachhaltigkeit / Verstetigung&lt;br /&gt;
&lt;br /&gt;
==RDMO Arbeitsgemeinschaft==&lt;br /&gt;
&lt;br /&gt;
Mit der Verabschiedung eines Memorandum of Understanding (MoU) wird das RDMO Projekt durch die RDMO Arbeitsgemeinschaft weitergeführt. &lt;br /&gt;
&lt;br /&gt;
Die RDMO Arbeitsgemeinschaft hat drei Arbeitsgruppen gebildet: Steuerungsgruppe , Softwaregruppe, Contentgruppe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Berichte==&lt;br /&gt;
&lt;br /&gt;
[[Erstes Community-Treffen|1. Community-Treffen]] (Essen, September 2018)&lt;br /&gt;
&lt;br /&gt;
[[Zweites Community-Treffen|2. Community-Treffen]] (Darmstadt, Oktober 2019)&lt;br /&gt;
&lt;br /&gt;
[[Drittes Community-Treffen|3. Community Treffen]] (Potsdam, Februar 2020)&lt;br /&gt;
&lt;br /&gt;
[[Viertes Community-Treffen|4. Community Treffen]] (Virtuell, Oktober 2020)&lt;br /&gt;
&lt;br /&gt;
[https://rdmorganiser.github.io/rdmo_arge/ MoU und RDMO Arbeitsgemeinschaft] (Virtuell, Februar 2021)&lt;br /&gt;
&lt;br /&gt;
[[Sechstes Community-Treffen|6. Community Treffen]] (Virtuell, Oktober 2021)&lt;br /&gt;
&lt;br /&gt;
[[Siebtes Community-Treffen|7. Community Treffen]] (Virtuell, März 2022)&lt;br /&gt;
&lt;br /&gt;
=Anleitungen=&lt;br /&gt;
&lt;br /&gt;
==Dokumentation==&lt;br /&gt;
&lt;br /&gt;
Die Dokumentation für die Installation und die Einrichtung von RDMO ist unter [http://rdmo.readthedocs.io/de/latest] zu finden.&lt;br /&gt;
&lt;br /&gt;
==Tutorials==&lt;br /&gt;
&amp;lt;span id=&amp;quot;RDMOTutorials&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;&lt;br /&gt;
Tutorials für RDMO sind auf der RDMO-Webseite unter [[https://rdmorganiser.github.io/tutorials/ Tutorials]] verlinkt, wir versuchen auch untenstehende Übersicht aktuell zu halten:&lt;br /&gt;
&lt;br /&gt;
*Schnellstart-Anleitung für Nutzer [[https://rdmorganiser.github.io/docs/Schnellstartanleitung.pdf PDF]]&lt;br /&gt;
*Schnellstart-Anleitung für Administratoren [[https://rdmorganiser.github.io/docs/SchnellstartanleitungAdminsv2.pdf PDF]]&lt;br /&gt;
*[[Katalog_erstellen|&amp;quot;Wie erstelle ich einen Fragenkatalog in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Ansicht_erstellen|&amp;quot;Wie erstelle ich eine Ansicht (View) in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Bedingung_erstellen|&amp;quot;Wie erstelle ich eine Bedingung in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Import_Export|&amp;quot;Wie importiere und exportiere ich XML-Dateien in RDMO?&amp;quot;]]&lt;br /&gt;
&lt;br /&gt;
==Frequently asked questions (FAQ)==&lt;br /&gt;
&lt;br /&gt;
[[RDMO_FAQ|Frequently asked questions]]&lt;br /&gt;
&lt;br /&gt;
==Verfügbares und in Vorbereitung befindliches Zubehör in der RDMO-Community==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!Institution&lt;br /&gt;
!Produkt, z.B. Fragenkatalog&lt;br /&gt;
!vor allem geeignet für&lt;br /&gt;
&lt;br /&gt;
!Benennung&amp;lt;br /&amp;gt;&lt;br /&gt;
!Ansprechpartner&lt;br /&gt;
!Status mit Link, falls verfügbar&lt;br /&gt;
!Beschreibung&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne (DMP) allgemein&lt;br /&gt;
|RDMO&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|generisch, detailliert&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Schweizer Nationalfonds&lt;br /&gt;
|SNF&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|Kurzer Fragenkatalog&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|Kurzversion des RDMO-Katalogs&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|DCC Checkliste 4.0&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|entwickelt nach DCC. (2013). Checklist for a Data Management Plan. v.4.0. Edinburgh: Digital Curation&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Ansicht&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG, 1. Version des DMP&lt;br /&gt;
|DFG&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten.pdf DFG-Leitlinien zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 101 Alte Kulturen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_101_forschungsdaten.pdf Handreichung zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Projekte mit mündlichen Korpora, 1. Version des DMP&lt;br /&gt;
|DFG 104 Mündlicher Korpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Textkorpora-Projekte, 1. Version des DMP&lt;br /&gt;
|DFG 104 Textkorpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 105 &amp;quot;Literaturwissenschaft&amp;quot;, Editionsprojekte, 1. Version des DMP&lt;br /&gt;
|DFG 105 Edition&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf Förderkriterien für wissenschaftliche Editionen in der Literaturwissenschaft]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 106, 1. Version des DMP&lt;br /&gt;
|DFG 106 Sozial- u. Kulturanthropologie, Außereurop. Kulturen, Judaistik u. Religionswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_106_forschungsdaten.pdf Handreichung des Fachkollegiums 106 Sozial- und Kulturanthropologie, Außereuropäische Kulturen, Judaistik und Religionswissenschaft zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 109 &amp;quot;Erziehungswissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 109 Bildungswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Petra Stanat, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_bildungsforschung.pdf Bereitstellung und Nutzung quantitativer Forschungsdaten in der Bildungsforschung: Memorandum des Fachkollegiums &amp;quot;Erziehungswissenschaft&amp;quot; der DFG]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 110 &amp;quot;Sozialwissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 110 Sozialwiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 111 &amp;quot;Wirtschaftswissenschaften&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 111 Wirtschaftswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement] und [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/fachkollegium112_forschungsdatenmanagement_de_1811.pdf Management von Forschungsdaten: Was erwartet das Fachkollegium 112 &amp;quot;Wirtschaftswissenschaften&amp;quot; von Antragstellenden?]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Projekte in der Biodiversitätsforschung&lt;br /&gt;
|DFG Biodiversitätsforschung&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_biodiversitaetsforschung.pdf Richtlinien zum Umgang mit Forschungsdaten in der Biodiversitätsforschung]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne allgemein&lt;br /&gt;
|Alle Fragen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|RDMO-Katalog erweitert um die Fragen in den anderen FoDaKo-Katalogen&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Unterstützung bei Beratungsgesprächen&lt;br /&gt;
|UA Ruhr-Beratung&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann vor einem Beratungsgespräch zu Datenmanagementplänen oder FDM allgemein ausgefüllt werden, als Grundlage für das Gespräch.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Antragstellung&lt;br /&gt;
|UA Ruhr-Antrag&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden um das Datenmanagement für einen Antrag dokumentieren zu können.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Zur Beantragung von Speicherplatz&lt;br /&gt;
|UA Ruhr-Archiv&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden, wenn geplant ist die Daten in einem zentralen Speicher, Archiv oder Repositorium abzulegen.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Forschungsdatenmanagement allgemein&lt;br /&gt;
|UA Ruhr&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|In diesem Katalog sind alle UARuhr-Fragen enthalten. Er behandelt umfassend die verschiedenen Aspekte des Forschungsdatenmanagements, deckt Anforderungen verschiedener Disziplinen ab, und ist daher recht umfangreich.&lt;br /&gt;
|-&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Weblinks==&lt;br /&gt;
&lt;br /&gt;
*RDMO-Projektwebseite: http://rdmorganiser.github.io/&lt;br /&gt;
*RDMO-GitHub Organisation und Quellcode: http://github.com/rdmorganiser&lt;br /&gt;
*RDMO-Demo-Instanz: http://rdmo.aip.de&lt;br /&gt;
&lt;br /&gt;
[[Kategorie:Projekte]]&lt;br /&gt;
[[Kategorie:Data Management]]&lt;br /&gt;
[[Kategorie:Open Science]]&lt;br /&gt;
[[Kategorie:Förderorganisationen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=7._RDMO_Communitytreffen&amp;diff=6947</id>
		<title>7. RDMO Communitytreffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=7._RDMO_Communitytreffen&amp;diff=6947"/>
		<updated>2022-03-24T13:39:18Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite 7. RDMO Communitytreffen nach Siebtes Communitytreffen&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#WEITERLEITUNG [[Siebtes Communitytreffen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6946</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6946"/>
		<updated>2022-03-24T13:39:18Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite 7. RDMO Communitytreffen nach Siebtes Communitytreffen&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Notizen zum RDMO-Treffen Breakout-Raum 2====&lt;br /&gt;
&lt;br /&gt;
=====Technik / Software=====&lt;br /&gt;
&lt;br /&gt;
*[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu RDMO Breakout-Raum 1====&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
- open development ok:[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|rahmenlos|600x600px|rechts]]&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6945</id>
		<title>RDMO</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6945"/>
		<updated>2022-03-24T13:38:24Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Berichte */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Projekt&lt;br /&gt;
|VollständigerName= Research Data Management Organiser&lt;br /&gt;
|ZeitraumVon= 01.11.2017&lt;br /&gt;
|ZeitraumBis= 30.04.2020&lt;br /&gt;
|Beteiligt=AIP, FH Potsdam, KIT&lt;br /&gt;
|Förderung= DFG bis 2020,  RDMO Arbeitsgemeinschaft ab 2020&lt;br /&gt;
|Website=http://rdmorganiser.github.io/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Der Research Data Management Organiser, kurz RDMO, ist ein Tool zur Erstellung von Datenmanagementplänen. Es wurde im Rahmen eines DFG-geförderten Projekts entwickelt und nun von einer RDMO-Arbeitsgemeinschaft weiter betreut, in der jeder mitarbeiten kann.&lt;br /&gt;
&lt;br /&gt;
=Einleitung=&lt;br /&gt;
Ziel des Projekts ist es, ein Werkzeug zur Verfügung zu stellen, das die strukturierte Planung, Umsetzung und Verwaltung des Forschungsdatenmanagements unterstützt und zusätzlich die textuelle Ausgabe eines Datenmanagementplans (DMP) ermöglicht. Ein Datenmanagementplan soll klären auf welche Art und Weise mit den anfallenden Forschungsdaten während, aber auch nach dem Ende eines Projekts, umgegangen werden soll. Es gilt beispielsweise zu klären in welchem Umfang Forschungsdaten anfallen, wie und wo diese gespeichert werden sollen und wer darauf zugreifen darf. Wie unter [[Data_Management_Pläne]] erklärt, gibt es bereits von verschiedenen Institutionen entwickelte Online-Tools: das Digital Curation Centre (DCC) in Großbritannien mit [http://dmponline.dcc.ac.uk DMPonline], die California Digital Library (CDL) mit dem [http://dmptool.org DMPTool] und in Deutschland das [http://data.uni-bielefeld.de/de/data-management-plan Online Tool für die Erstellung eines DMP] der Universität Bielefeld.&lt;br /&gt;
&lt;br /&gt;
=Geschichte/Entwicklung=&lt;br /&gt;
&lt;br /&gt;
==Erste Projektphase==&lt;br /&gt;
&lt;br /&gt;
Die erste Projektphase dauerte von November 2015 bis April 2017 und diente der Entwicklung von RDMO. &lt;br /&gt;
&lt;br /&gt;
Der Hauptzweck von Tools zur Erstellung von DMPs ist es, den Vorgaben des jeweiligen Förderers zu entsprechen und die einmalige Erstellung eines DMPs zu unterstützen. Das Ziel von RDMO ist jedoch eine Nutzung, die über die Antragsstellung hinausgeht. So kann das Erstellen eines DMPs die Planung des Forschungsdatenmanagements im Vorfeld optimieren und der Datenmanagementplan schließlich das ganze Projekt lang begleiten und unterstützen, in dem er als Leitfaden dient. Dies könnte die Effizienz und die Qualität der wissenschaftlichen Arbeit erhöhen und somit auch die Motivation der Forschenden solch einen DMP zu erstellen. Die Zielgruppe sind jedoch nicht nur die Forschende selbst, sondern auch alle im Forschungsdatenmanagement Involvierten. Das Tool ist für die verschiedensten Disziplinen und Institute anpassbar und einsetzbar. Das Online-Tool wird derzeit auf Deutsch und Englisch angeboten.&lt;br /&gt;
&lt;br /&gt;
==Zweite Projektphase==&lt;br /&gt;
&lt;br /&gt;
Das RDMO-Projekt befindet sich derzeit in der zweiten Pojektphase, die von November 2017 bis April 2020 läuft.&lt;br /&gt;
&lt;br /&gt;
Die Ziele für die zweite Projektphase sind insbesondere:&lt;br /&gt;
&lt;br /&gt;
*Erweiterung des Organisers: Rollenkonzept, Kostenabschätzung, Ingest-Prozess, Interoperabilität&lt;br /&gt;
&lt;br /&gt;
*Integration in die Infrastruktur: standardisierte Installation, Wartbarkeit, Ausbau der untersützten Authentifizierungs- und Autorisierungs-Systeme&lt;br /&gt;
&lt;br /&gt;
*Etablierung in der Community&lt;br /&gt;
&lt;br /&gt;
*Nachhaltigkeit / Verstetigung&lt;br /&gt;
&lt;br /&gt;
==RDMO Arbeitsgemeinschaft==&lt;br /&gt;
&lt;br /&gt;
Mit der Verabschiedung eines Memorandum of Understanding (MoU) wird das RDMO Projekt durch die RDMO Arbeitsgemeinschaft weitergeführt. &lt;br /&gt;
&lt;br /&gt;
Die RDMO Arbeitsgemeinschaft hat drei Arbeitsgruppen gebildet: Steuerungsgruppe , Softwaregruppe, Contentgruppe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Berichte==&lt;br /&gt;
&lt;br /&gt;
[[Erstes Community-Treffen|1. Community-Treffen]] (Essen, September 2018)&lt;br /&gt;
&lt;br /&gt;
[[Zweites Community-Treffen|2. Community-Treffen]] (Darmstadt, Oktober 2019)&lt;br /&gt;
&lt;br /&gt;
[[Drittes Community-Treffen|3. Community Treffen]] (Potsdam, Februar 2020)&lt;br /&gt;
&lt;br /&gt;
[[Viertes Community-Treffen|4. Community Treffen]] (Virtuell, Oktober 2020)&lt;br /&gt;
&lt;br /&gt;
[https://rdmorganiser.github.io/rdmo_arge/ MoU und RDMO Arbeitsgemeinschaft] (Virtuell, Februar 2021)&lt;br /&gt;
&lt;br /&gt;
[[Sechstes Community-Treffen|6. Community Treffen]] (Virtuell, Oktober 2021)&lt;br /&gt;
&lt;br /&gt;
[[Siebtes Community-Treffen|7. Community Treffen]] (Virtuell, Oktober 2021)&lt;br /&gt;
&lt;br /&gt;
=Anleitungen=&lt;br /&gt;
&lt;br /&gt;
==Dokumentation==&lt;br /&gt;
&lt;br /&gt;
Die Dokumentation für die Installation und die Einrichtung von RDMO ist unter [http://rdmo.readthedocs.io/de/latest] zu finden.&lt;br /&gt;
&lt;br /&gt;
==Tutorials==&lt;br /&gt;
&amp;lt;span id=&amp;quot;RDMOTutorials&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;&lt;br /&gt;
Tutorials für RDMO sind auf der RDMO-Webseite unter [[https://rdmorganiser.github.io/tutorials/ Tutorials]] verlinkt, wir versuchen auch untenstehende Übersicht aktuell zu halten:&lt;br /&gt;
&lt;br /&gt;
*Schnellstart-Anleitung für Nutzer [[https://rdmorganiser.github.io/docs/Schnellstartanleitung.pdf PDF]]&lt;br /&gt;
*Schnellstart-Anleitung für Administratoren [[https://rdmorganiser.github.io/docs/SchnellstartanleitungAdminsv2.pdf PDF]]&lt;br /&gt;
*[[Katalog_erstellen|&amp;quot;Wie erstelle ich einen Fragenkatalog in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Ansicht_erstellen|&amp;quot;Wie erstelle ich eine Ansicht (View) in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Bedingung_erstellen|&amp;quot;Wie erstelle ich eine Bedingung in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Import_Export|&amp;quot;Wie importiere und exportiere ich XML-Dateien in RDMO?&amp;quot;]]&lt;br /&gt;
&lt;br /&gt;
==Frequently asked questions (FAQ)==&lt;br /&gt;
&lt;br /&gt;
[[RDMO_FAQ|Frequently asked questions]]&lt;br /&gt;
&lt;br /&gt;
==Verfügbares und in Vorbereitung befindliches Zubehör in der RDMO-Community==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!Institution&lt;br /&gt;
!Produkt, z.B. Fragenkatalog&lt;br /&gt;
!vor allem geeignet für&lt;br /&gt;
&lt;br /&gt;
!Benennung&amp;lt;br /&amp;gt;&lt;br /&gt;
!Ansprechpartner&lt;br /&gt;
!Status mit Link, falls verfügbar&lt;br /&gt;
!Beschreibung&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne (DMP) allgemein&lt;br /&gt;
|RDMO&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|generisch, detailliert&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Schweizer Nationalfonds&lt;br /&gt;
|SNF&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|Kurzer Fragenkatalog&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|Kurzversion des RDMO-Katalogs&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|DCC Checkliste 4.0&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|entwickelt nach DCC. (2013). Checklist for a Data Management Plan. v.4.0. Edinburgh: Digital Curation&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Ansicht&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG, 1. Version des DMP&lt;br /&gt;
|DFG&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten.pdf DFG-Leitlinien zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 101 Alte Kulturen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_101_forschungsdaten.pdf Handreichung zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Projekte mit mündlichen Korpora, 1. Version des DMP&lt;br /&gt;
|DFG 104 Mündlicher Korpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Textkorpora-Projekte, 1. Version des DMP&lt;br /&gt;
|DFG 104 Textkorpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 105 &amp;quot;Literaturwissenschaft&amp;quot;, Editionsprojekte, 1. Version des DMP&lt;br /&gt;
|DFG 105 Edition&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf Förderkriterien für wissenschaftliche Editionen in der Literaturwissenschaft]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 106, 1. Version des DMP&lt;br /&gt;
|DFG 106 Sozial- u. Kulturanthropologie, Außereurop. Kulturen, Judaistik u. Religionswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_106_forschungsdaten.pdf Handreichung des Fachkollegiums 106 Sozial- und Kulturanthropologie, Außereuropäische Kulturen, Judaistik und Religionswissenschaft zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 109 &amp;quot;Erziehungswissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 109 Bildungswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Petra Stanat, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_bildungsforschung.pdf Bereitstellung und Nutzung quantitativer Forschungsdaten in der Bildungsforschung: Memorandum des Fachkollegiums &amp;quot;Erziehungswissenschaft&amp;quot; der DFG]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 110 &amp;quot;Sozialwissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 110 Sozialwiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 111 &amp;quot;Wirtschaftswissenschaften&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 111 Wirtschaftswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement] und [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/fachkollegium112_forschungsdatenmanagement_de_1811.pdf Management von Forschungsdaten: Was erwartet das Fachkollegium 112 &amp;quot;Wirtschaftswissenschaften&amp;quot; von Antragstellenden?]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Projekte in der Biodiversitätsforschung&lt;br /&gt;
|DFG Biodiversitätsforschung&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_biodiversitaetsforschung.pdf Richtlinien zum Umgang mit Forschungsdaten in der Biodiversitätsforschung]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne allgemein&lt;br /&gt;
|Alle Fragen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|RDMO-Katalog erweitert um die Fragen in den anderen FoDaKo-Katalogen&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Unterstützung bei Beratungsgesprächen&lt;br /&gt;
|UA Ruhr-Beratung&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann vor einem Beratungsgespräch zu Datenmanagementplänen oder FDM allgemein ausgefüllt werden, als Grundlage für das Gespräch.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Antragstellung&lt;br /&gt;
|UA Ruhr-Antrag&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden um das Datenmanagement für einen Antrag dokumentieren zu können.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Zur Beantragung von Speicherplatz&lt;br /&gt;
|UA Ruhr-Archiv&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden, wenn geplant ist die Daten in einem zentralen Speicher, Archiv oder Repositorium abzulegen.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Forschungsdatenmanagement allgemein&lt;br /&gt;
|UA Ruhr&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|In diesem Katalog sind alle UARuhr-Fragen enthalten. Er behandelt umfassend die verschiedenen Aspekte des Forschungsdatenmanagements, deckt Anforderungen verschiedener Disziplinen ab, und ist daher recht umfangreich.&lt;br /&gt;
|-&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Weblinks==&lt;br /&gt;
&lt;br /&gt;
*RDMO-Projektwebseite: http://rdmorganiser.github.io/&lt;br /&gt;
*RDMO-GitHub Organisation und Quellcode: http://github.com/rdmorganiser&lt;br /&gt;
*RDMO-Demo-Instanz: http://rdmo.aip.de&lt;br /&gt;
&lt;br /&gt;
[[Kategorie:Projekte]]&lt;br /&gt;
[[Kategorie:Data Management]]&lt;br /&gt;
[[Kategorie:Open Science]]&lt;br /&gt;
[[Kategorie:Förderorganisationen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6944</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6944"/>
		<updated>2022-03-24T13:36:57Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Notizen zum RDMO-Treffen Breakout-Raum 2====&lt;br /&gt;
&lt;br /&gt;
=====Technik / Software=====&lt;br /&gt;
&lt;br /&gt;
*[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu RDMO Breakout-Raum 1====&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
- open development ok:[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|rahmenlos|600x600px|rechts]]&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6943</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6943"/>
		<updated>2022-03-24T13:33:50Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Notizen zu Breakout Raum 1 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Notizen zum RDMO-Treffen Breakout-Raum 2====&lt;br /&gt;
&lt;br /&gt;
=====Technik / Software =====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil =====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu RDMO Breakout-Raum 1====&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|rahmenlos|600x600px|rechts]]&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6942</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6942"/>
		<updated>2022-03-24T13:31:29Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Notizen zum RDMO-Treffen Breakout-Raum 2====&lt;br /&gt;
&lt;br /&gt;
=====Technische Dimension=====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]&lt;br /&gt;
&lt;br /&gt;
=====Inhalte=====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu Breakout Raum 1====&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|rahmenlos|600x600px|rechts]]&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6941</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6941"/>
		<updated>2022-03-24T13:29:38Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Einzelne Notizen zum RDMO-Treffen Raum 2 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Einzelne Notizen zum RDMO-Treffen Raum 2====&lt;br /&gt;
&lt;br /&gt;
====Technische Dimension====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]&lt;br /&gt;
&lt;br /&gt;
====Inhalte====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu Breakout Raum 1====&lt;br /&gt;
&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|rahmenlos|600x600px|rechts]]&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6940</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6940"/>
		<updated>2022-03-24T13:26:39Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Inhalte */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Einzelne Notizen zum RDMO-Treffen Raum 2====&lt;br /&gt;
&lt;br /&gt;
====Technische Dimension====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
====Inhalte====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu Breakout Raum 1====&lt;br /&gt;
&lt;br /&gt;
===== Content-Teil =====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6939</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6939"/>
		<updated>2022-03-24T13:25:35Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Inhalte */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Einzelne Notizen zum RDMO-Treffen Raum 2====&lt;br /&gt;
&lt;br /&gt;
====Technische Dimension====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
====Inhalte====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu Breakout Raum 1====&lt;br /&gt;
&lt;br /&gt;
===== Content-Teil =====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6938</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6938"/>
		<updated>2022-03-24T13:24:21Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Technik/Software */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Einzelne Notizen zum RDMO-Treffen Raum 2====&lt;br /&gt;
&lt;br /&gt;
====Technische Dimension====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
====Inhalte====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Notizen zu Breakout Raum 1====&lt;br /&gt;
&lt;br /&gt;
===== Content-Teil =====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
        Features List fuer Versionen erwünscht &lt;br /&gt;
        Release Zeitpunkt machen  &lt;br /&gt;
        Github Issue Votings  &lt;br /&gt;
        oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
        “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6937</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6937"/>
		<updated>2022-03-24T13:22:18Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Einzelne Notizen zum RDMO-Treffen Raum 2====&lt;br /&gt;
&lt;br /&gt;
====Technische Dimension====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
====Inhalte====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Notizen zu Breakout Raum 1====&lt;br /&gt;
&lt;br /&gt;
===== Content-Teil =====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht) &lt;br /&gt;
&lt;br /&gt;
- Statistiken … horizon / DFG template &lt;br /&gt;
&lt;br /&gt;
- Sammlung der Kataloge ( )  &lt;br /&gt;
&lt;br /&gt;
=====Technik/Software=====&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht &lt;br /&gt;
&lt;br /&gt;
- Release Zeitpunkt machen  &lt;br /&gt;
&lt;br /&gt;
- Github Issue Votings  &lt;br /&gt;
&lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed  &lt;br /&gt;
&lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
        Issues / Features Diskussion evtl. regelmässig organisieren &lt;br /&gt;
&lt;br /&gt;
        Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
&lt;br /&gt;
        Crash-Course RDMO development? &lt;br /&gt;
&lt;br /&gt;
        Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Hereinnahme von anderen  Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6936</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6936"/>
		<updated>2022-03-24T12:38:44Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Notizen zu Raum 1 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Einzelne Notizen zum RDMO-Treffen Raum 2====&lt;br /&gt;
&lt;br /&gt;
====Technische Dimension====&lt;br /&gt;
&lt;br /&gt;
*Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Fragen /  Punkte :&lt;br /&gt;
**entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
**Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
**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.&lt;br /&gt;
**Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO&lt;br /&gt;
**die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
**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.&lt;br /&gt;
&lt;br /&gt;
*Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
**Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.&lt;br /&gt;
&lt;br /&gt;
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
**Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
*Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
====Inhalte====&lt;br /&gt;
&lt;br /&gt;
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
**Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
*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?&lt;br /&gt;
&lt;br /&gt;
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
**Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.&lt;br /&gt;
&lt;br /&gt;
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?&lt;br /&gt;
*Stellt Github hier eine Barriere da?&lt;br /&gt;
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
**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.&lt;br /&gt;
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
*Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Notizen zu Breakout Raum 1====&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
=====Content-Teil=====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
===== Technik/Software =====&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6935</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6935"/>
		<updated>2022-03-24T12:34:37Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Einzelne Notizen zum RDMO-Treffen Raum 2 ====&lt;br /&gt;
&lt;br /&gt;
==== Technische Dimension ====&lt;br /&gt;
&lt;br /&gt;
* Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
* Fragen /  Punkte :&lt;br /&gt;
** entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird? &lt;br /&gt;
** Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...) &lt;br /&gt;
** 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. &lt;br /&gt;
** Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
* Modularität von RDMO&lt;br /&gt;
** die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
* Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
** 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.&lt;br /&gt;
&lt;br /&gt;
* Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
** Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
* Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
** Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
* Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
** Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
==== Inhalte ====&lt;br /&gt;
&lt;br /&gt;
* Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
** Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
* 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?&lt;br /&gt;
&lt;br /&gt;
* Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
** Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
* Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
* Stellt Github hier eine Barriere da? &lt;br /&gt;
* Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
** Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
** 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.&lt;br /&gt;
** Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
** Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
* Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
* Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Notizen zu Raum 1 ====&lt;br /&gt;
&lt;br /&gt;
==== Content-Teil ====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6934</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6934"/>
		<updated>2022-03-24T12:33:27Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Einzelne Notizen zum RDMO-Treffen Raum 2 ====&lt;br /&gt;
&lt;br /&gt;
==== Technische Dimension ====&lt;br /&gt;
&lt;br /&gt;
* Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
**Content ist meist drängender als Technik&lt;br /&gt;
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
**Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
* Fragen /  Punkte :&lt;br /&gt;
** entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird? &lt;br /&gt;
** Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...) &lt;br /&gt;
** 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. &lt;br /&gt;
** Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
* Modularität von RDMO&lt;br /&gt;
** die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
* Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
** 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.&lt;br /&gt;
&lt;br /&gt;
* Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
** Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
* Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
** Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
* Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
** Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.&lt;br /&gt;
&lt;br /&gt;
==== Inhalte ====&lt;br /&gt;
&lt;br /&gt;
* Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
** Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
* 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?&lt;br /&gt;
&lt;br /&gt;
* Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben  &lt;br /&gt;
** Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
* Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
* Stellt Github hier eine Barriere da? &lt;br /&gt;
* Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?&lt;br /&gt;
** Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
** 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.&lt;br /&gt;
** Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
** Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
* Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
* Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Notizen zu Raum 1 ====&lt;br /&gt;
&lt;br /&gt;
==== Content-Teil ====&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6933</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6933"/>
		<updated>2022-03-24T12:16:03Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
#Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
ntscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6932</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6932"/>
		<updated>2022-03-24T12:08:14Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
*Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
*Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
#Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
ntscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines? &lt;br /&gt;
&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade [[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|links]]&lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|links|rahmenlos|600x600px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6931</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6931"/>
		<updated>2022-03-24T11:58:59Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
* Erste Entwicklungswünsche &lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
* Abschluss &lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f536.png|mini|Breakout room input collection]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Datei:C05296f20b96fd93af8f5f536.png&amp;diff=6930</id>
		<title>Datei:C05296f20b96fd93af8f5f536.png</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Datei:C05296f20b96fd93af8f5f536.png&amp;diff=6930"/>
		<updated>2022-03-24T11:56:56Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Input collection Breakout session&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6929</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6929"/>
		<updated>2022-03-24T11:53:17Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
* Erste Entwicklungswünsche &lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
* Abschluss &lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;br /&gt;
&lt;br /&gt;
![Input Collection 1](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f537.png)&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6928</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6928"/>
		<updated>2022-03-24T11:48:49Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
===&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
*Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
*Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
* Erste Entwicklungswünsche &lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
&lt;br /&gt;
-- graphische IDE für Content-Entwicklung  &lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability &lt;br /&gt;
&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO  &lt;br /&gt;
&lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit &lt;br /&gt;
&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür &lt;br /&gt;
&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
* Abschluss &lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6927</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6927"/>
		<updated>2022-03-24T11:43:01Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
=== &#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039; ===&lt;br /&gt;
&lt;br /&gt;
==== &#039;&#039;&#039;Content-Themen&#039;&#039;&#039; ====&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
*  Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)&lt;br /&gt;
&lt;br /&gt;
* Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
* Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
==== &#039;&#039;&#039;Technik / Software&#039;&#039;&#039; ====&lt;br /&gt;
&lt;br /&gt;
*Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
*Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse  &lt;br /&gt;
&lt;br /&gt;
Erste Entwicklungswünsche &lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6926</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6926"/>
		<updated>2022-03-24T11:39:11Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
*Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
* Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6925</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6925"/>
		<updated>2022-03-24T11:35:01Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Notizen zum RDMO-Treffen Breakout-Raum &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
*Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
* Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Notizen zum RDMO-Treffen Raum 2&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Technik / Software&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
* Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung &lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen &lt;br /&gt;
&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten  &lt;br /&gt;
&lt;br /&gt;
-- Workflow für GitHub-Requests &lt;br /&gt;
&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6924</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6924"/>
		<updated>2022-03-24T11:28:44Z</updated>

		<summary type="html">&lt;p&gt;Harry: editing/formatting content...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Content-Themen&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutzung&lt;br /&gt;
&lt;br /&gt;
* Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Die Roadmap soll nicht nur technische Aspekte, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, …) abdecken. Ein offener Prozess ist wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
#Lessons learnt&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
#Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
*Content ist meist drängender als Technik&lt;br /&gt;
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
*Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6923</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6923"/>
		<updated>2022-03-24T11:23:49Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# Content-Themen&lt;br /&gt;
&lt;br /&gt;
* Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
# Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechst&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
# Lessons learnt&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
# Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
* Content ist meist drängender als Technik&lt;br /&gt;
* Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
* Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
### Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6922</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6922"/>
		<updated>2022-03-24T11:14:08Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== &lt;br /&gt;
&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe &lt;br /&gt;
wurden 2x2 Breakout-Sessions gemacht unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
 Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&#039;&#039;&#039;Zusammenfassung der Mitschriften&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Content-Theme&lt;br /&gt;
&lt;br /&gt;
** Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&lt;br /&gt;
*Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&lt;br /&gt;
#Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechst&lt;br /&gt;
&lt;br /&gt;
###Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
- Content ist meist drängender als Technik&lt;br /&gt;
- Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
- Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
- Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6921</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6921"/>
		<updated>2022-03-24T11:05:37Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{DISPLAYTITLE:7. RDMO Communitytreffen}}&lt;br /&gt;
&lt;br /&gt;
== &lt;br /&gt;
&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht&lt;br /&gt;
unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
 Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
#Zusammenfassung der Mitschriften&lt;br /&gt;
&lt;br /&gt;
##Content-Themen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
- Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&lt;br /&gt;
###Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
###Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|zentriert|rahmenlos|600x600px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
- Content ist meist drängender als Technik&lt;br /&gt;
- Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
- Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
- Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6920</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6920"/>
		<updated>2022-03-24T11:03:25Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{DISPLAYTITLE:7. RDMO Communitytreffen}}&lt;br /&gt;
&lt;br /&gt;
== &lt;br /&gt;
&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht&lt;br /&gt;
unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
 Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
#Zusammenfassung der Mitschriften&lt;br /&gt;
&lt;br /&gt;
##Content-Themen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
- Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&lt;br /&gt;
###Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
###Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
- Content ist meist drängender als Technik&lt;br /&gt;
- Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
- Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
- Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
[[Datei:C05296f20b96fd93af8f5f537.png|zentriert|rahmenlos|600x600px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Datei:C05296f20b96fd93af8f5f537.png&amp;diff=6919</id>
		<title>Datei:C05296f20b96fd93af8f5f537.png</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Datei:C05296f20b96fd93af8f5f537.png&amp;diff=6919"/>
		<updated>2022-03-24T11:01:30Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Input Map des RDMO-Workshops&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6918</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6918"/>
		<updated>2022-03-24T10:59:48Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* 7. Communitytreffen */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{DISPLAYTITLE:7. RDMO Communitytreffen}}&lt;br /&gt;
&lt;br /&gt;
== &lt;br /&gt;
&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht&lt;br /&gt;
unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
 Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
#Zusammenfassung der Mitschriften&lt;br /&gt;
&lt;br /&gt;
##Content-Themen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
- Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&lt;br /&gt;
###Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
###Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
- Content ist meist drängender als Technik&lt;br /&gt;
- Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
- Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
- Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
![Input collection](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f537.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=New_page&amp;diff=6917</id>
		<title>New page</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=New_page&amp;diff=6917"/>
		<updated>2022-03-24T10:58:03Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite New page nach RDMO-7-Communitytreffen: new page is no real page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#WEITERLEITUNG [[RDMO-7-Communitytreffen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=RDMO-7-Communitytreffen&amp;diff=6916</id>
		<title>RDMO-7-Communitytreffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=RDMO-7-Communitytreffen&amp;diff=6916"/>
		<updated>2022-03-24T10:58:03Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite New page nach RDMO-7-Communitytreffen: new page is no real page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#WEITERLEITUNG [[7. RDMO Communitytreffen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=RDMO-7-Communitytreffen&amp;diff=6915</id>
		<title>RDMO-7-Communitytreffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=RDMO-7-Communitytreffen&amp;diff=6915"/>
		<updated>2022-03-24T10:57:16Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite New page nach 7. RDMO Communitytreffen: new page is no real page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#WEITERLEITUNG [[7. RDMO Communitytreffen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6914</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6914"/>
		<updated>2022-03-24T10:57:16Z</updated>

		<summary type="html">&lt;p&gt;Harry: Harry verschob die Seite New page nach 7. RDMO Communitytreffen: new page is no real page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{DISPLAYTITLE:7. RDMO Communitytreffen}}&lt;br /&gt;
&lt;br /&gt;
== &lt;br /&gt;
==7. Communitytreffen==&lt;br /&gt;
==&lt;br /&gt;
&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt. &lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht&lt;br /&gt;
unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
 Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
 [toc]&lt;br /&gt;
&lt;br /&gt;
#Zusammenfassung der Mitschriften&lt;br /&gt;
&lt;br /&gt;
##Content-Themen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
- Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&lt;br /&gt;
###Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
###Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
- Content ist meist drängender als Technik&lt;br /&gt;
- Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
- Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
- Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
![Input collection](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f537.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6913</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6913"/>
		<updated>2022-03-24T10:56:15Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{DISPLAYTITLE:7. RDMO Communitytreffen}}&lt;br /&gt;
&lt;br /&gt;
== &lt;br /&gt;
==7. Communitytreffen==&lt;br /&gt;
==&lt;br /&gt;
&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt. &lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht&lt;br /&gt;
unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
*Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
*Technische Dimension - Moderation:  Jochen Klar&lt;br /&gt;
&lt;br /&gt;
 Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
 [toc]&lt;br /&gt;
&lt;br /&gt;
#Zusammenfassung der Mitschriften&lt;br /&gt;
&lt;br /&gt;
##Content-Themen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Konkrete Bedarfe&lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
###Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
- Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&lt;br /&gt;
###Community-Beteiligung&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
###Lessons learnt&lt;br /&gt;
&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik / Software&lt;br /&gt;
&lt;br /&gt;
###Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
####Erste Entwicklungswünsche&lt;br /&gt;
&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zum RDMO-Treffen Raum 2&lt;br /&gt;
&lt;br /&gt;
##Technische Dimension&lt;br /&gt;
&lt;br /&gt;
###Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
- Content ist meist drängender als Technik&lt;br /&gt;
- Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
- Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
###Fragen /  Punkte :&lt;br /&gt;
&lt;br /&gt;
- Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
![Input collection](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f537.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
###Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
#Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
##Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
##Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6912</id>
		<title>Siebtes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Siebtes_Community-Treffen&amp;diff=6912"/>
		<updated>2022-03-24T10:54:10Z</updated>

		<summary type="html">&lt;p&gt;Harry: Draft des Reports&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== &lt;br /&gt;
== 7. Communitytreffen  ==&lt;br /&gt;
==&lt;br /&gt;
&lt;br /&gt;
Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt. &lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Nach drei kurzen Reports aus&lt;br /&gt;
Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht&lt;br /&gt;
unter dem Thema: &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Dimensionen einer RDMO Roadmap (2 Räume, 2x 20 min.)&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* Inhaltliche Dimension - Moderation: Robert Strötgen&lt;br /&gt;
* Technische Dimension - Moderation:  Jochen Klar &lt;br /&gt;
&lt;br /&gt;
 Im Folgenden sind Minutes dokumentiert, die fuer einen weiteren geplanten Workshop ausgewertet werden.&lt;br /&gt;
&lt;br /&gt;
 [toc]&lt;br /&gt;
&lt;br /&gt;
# Zusammenfassung der Mitschriften&lt;br /&gt;
&lt;br /&gt;
## Content-Themen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
### Konkrete Bedarfe&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- 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. &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.) &lt;br /&gt;
&lt;br /&gt;
- Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.&lt;br /&gt;
&lt;br /&gt;
- Einfaches Klonen von Datensätzen / Projekten in RDMO.&lt;br /&gt;
&lt;br /&gt;
- 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
### Bereits etablierte/s Dienste / Vorgehen&lt;br /&gt;
&lt;br /&gt;
- Wachsendes Portfolio an geteilten Plänen / Vorlagen.&lt;br /&gt;
- offener Entwicklungsprozess (Open development)&lt;br /&gt;
- große Auswahl an Optionensätze erleichtern RDMO-Nutznung&lt;br /&gt;
&lt;br /&gt;
### Community-Beteiligung&lt;br /&gt;
- 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.&lt;br /&gt;
- Wege am Entwicklungsprozess mitzuwirken besser darstellen:&lt;br /&gt;
-- Zugang zum Slack ist momentan nur auf Einladung möglich&lt;br /&gt;
-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?&lt;br /&gt;
-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren&lt;br /&gt;
-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)&lt;br /&gt;
&lt;br /&gt;
### Lessons learnt&lt;br /&gt;
- Content muss laufend gepflegt werden&lt;br /&gt;
- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
## Technik / Software&lt;br /&gt;
&lt;br /&gt;
### Diskussionsgrundlage aus der RDMO-Software-AG&lt;br /&gt;
&lt;br /&gt;
- 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.&lt;br /&gt;
- Anforderungen an den Content sind meist drängender als an die Technik / Software&lt;br /&gt;
- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
### Zusammenfassung des Brainstormings&lt;br /&gt;
&lt;br /&gt;
-  Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?&lt;br /&gt;
-- 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.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.&lt;br /&gt;
-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.&lt;br /&gt;
-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO ist für Anwender wichtig, das Plugin-Konzept kann hierfür verstärkt eingesetzt werden&lt;br /&gt;
&lt;br /&gt;
- Ausbau des Entwicklerpools&lt;br /&gt;
-- Crash-Kurs für Einsteiger in die Entwicklung&lt;br /&gt;
-- Mehr Informationen zur Plugin-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- Festlegen von Entwicklungsguidelines und -Plänen&lt;br /&gt;
-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten &lt;br /&gt;
-- Workflow für GitHub-Requests&lt;br /&gt;
-- erhöht Tranparenz der Prozesse &lt;br /&gt;
&lt;br /&gt;
#### Erste Entwicklungswünsche&lt;br /&gt;
- Verbessertes User-Interface&lt;br /&gt;
-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)&lt;br /&gt;
-- graphische IDE für Content-Entwicklung&lt;br /&gt;
&lt;br /&gt;
- &amp;quot;Terms-of-Use&amp;quot; für mehr Authentifizierungsoptionen  &lt;br /&gt;
&lt;br /&gt;
- Möglichkeiten zum Vergleich von Kataloginhalten (--&amp;gt; ggf. auch Frage der Content-Bereit- und -Darstellung)&lt;br /&gt;
&lt;br /&gt;
- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability&lt;br /&gt;
-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO &lt;br /&gt;
-- Datenübernahmen ersparten Doppelarbeit&lt;br /&gt;
-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür&lt;br /&gt;
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
# Abschluss&lt;br /&gt;
&lt;br /&gt;
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?&lt;br /&gt;
- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen&lt;br /&gt;
- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.&lt;br /&gt;
- 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
# Einzelne Notizen zum RDMO-Treffen Raum 2 &lt;br /&gt;
&lt;br /&gt;
## Technische Dimension&lt;br /&gt;
&lt;br /&gt;
### Drei Punkte vorneweg für die Diskussion:&lt;br /&gt;
&lt;br /&gt;
- Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.&lt;br /&gt;
- Content ist meist drängender als Technik&lt;br /&gt;
- Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?&lt;br /&gt;
- Das &amp;quot;wer&amp;quot; ist dann der nächste Schritt.&lt;br /&gt;
&lt;br /&gt;
### Fragen /  Punkte :&lt;br /&gt;
- Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?&lt;br /&gt;
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Modularität von RDMO&lt;br /&gt;
-- die Plugins sind ein wichtiger Schritt in diese Richtung&lt;br /&gt;
&lt;br /&gt;
- Gibt es schon FIS/CRIS, die mit RDMO verbunden sind&lt;br /&gt;
-- 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.&lt;br /&gt;
&lt;br /&gt;
- Gibt es Entwicklungs-Guidelines?&lt;br /&gt;
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich. &lt;br /&gt;
&lt;br /&gt;
- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.&lt;br /&gt;
&lt;br /&gt;
- Wie ist der Workflow für Requests in GitHub?&lt;br /&gt;
&lt;br /&gt;
- Was sind Roadmaps in anderen Open Source Projekten?&lt;br /&gt;
-- Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
![Input collection](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f537.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
## Inhalte - Teil 2&lt;br /&gt;
&lt;br /&gt;
### Punkte:&lt;br /&gt;
&lt;br /&gt;
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken? &lt;br /&gt;
-- Das ist sinnvoll und besonders wichtig für die Transparenz.&lt;br /&gt;
&lt;br /&gt;
- 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?&lt;br /&gt;
&lt;br /&gt;
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben&lt;br /&gt;
-- Basale Informationen (Förderer,...) sollten als &amp;quot;Projektmetadaten&amp;quot; hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.  &lt;br /&gt;
&lt;br /&gt;
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen? &lt;br /&gt;
-- Stellt Github hier eine Barriere da? &lt;br /&gt;
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen? &lt;br /&gt;
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.&lt;br /&gt;
-- 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.&lt;br /&gt;
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.&lt;br /&gt;
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten&lt;br /&gt;
&lt;br /&gt;
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?&lt;br /&gt;
&lt;br /&gt;
- Notsituation &amp;quot;DMP wird schnell benötigt&amp;quot; nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.&lt;br /&gt;
&lt;br /&gt;
![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
# Einzelne Notizen zu Raum 1&lt;br /&gt;
&lt;br /&gt;
## Content-Teil&lt;br /&gt;
&lt;br /&gt;
- open development ok:&lt;br /&gt;
        Templates für Datenstrukturen &lt;br /&gt;
        Clonen von Datensätzen &lt;br /&gt;
- einfaches Ausfüllen : 2-3 Detaillierungsgrade &lt;br /&gt;
        verschiedene Level&lt;br /&gt;
- RDMO =&amp;gt; generierung von DMP &lt;br /&gt;
        =&amp;gt;Organiser Funktionen verbessern&lt;br /&gt;
        -&amp;gt; Rechte verteilungen&lt;br /&gt;
        -&amp;gt; Nutzerkomfort  verbessern (Anmerkungen?) &lt;br /&gt;
- “Expertenhilfe” organisieren ?&lt;br /&gt;
  ‘zuweisen’ von Fragen an Experten ? &lt;br /&gt;
- 20-30 Kataloge bei Mandanten-Version (übersicht)&lt;br /&gt;
- Statistiken … horizon / DFG template&lt;br /&gt;
- Sammlung der Kataloge ( ) &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
## Technik/Software&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Planung der Entwicklung: &lt;br /&gt;
- Features List fuer Versionen erwünscht&lt;br /&gt;
- Release Zeitpunkt machen &lt;br /&gt;
- Github Issue Votings &lt;br /&gt;
- oder etwas, das ‘abstraktere’ Features managed &lt;br /&gt;
- “Projekte” aus Github kostenlos nutzen? &lt;br /&gt;
&lt;br /&gt;
Entwicklungsprozess muss Mittel und Bedarfe matchen&lt;br /&gt;
&lt;br /&gt;
Issues / Features Diskussion evtl. regelmässig organisieren&lt;br /&gt;
Label für Issues um Prozess/Diskussion transparenter zu machen &lt;br /&gt;
&lt;br /&gt;
=&amp;gt; mehrere Entwickler benötigt: &lt;br /&gt;
Crash-Course RDMO development? &lt;br /&gt;
Einführungskurs (JK) evtl. wiederholen &lt;br /&gt;
Plugin Entwicklung&lt;br /&gt;
 &lt;br /&gt;
=&amp;gt; Hereinnahme von anderen   Funktionen als DMP Produktion&lt;br /&gt;
        Schnittstellen  zu anderen Systemen&lt;br /&gt;
        Software management&lt;br /&gt;
Projektmanagement ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=&amp;gt; Beteiligung durch SHK oder andere Ressourcen …..&lt;br /&gt;
        Betreuung durch RDMO &lt;br /&gt;
        Content &lt;br /&gt;
        Software Elemente&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6911</id>
		<title>RDMO</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=RDMO&amp;diff=6911"/>
		<updated>2022-03-24T10:23:26Z</updated>

		<summary type="html">&lt;p&gt;Harry: entered AG as Open Source Porject&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Projekt&lt;br /&gt;
|VollständigerName= Research Data Management Organiser&lt;br /&gt;
|ZeitraumVon= 01.11.2017&lt;br /&gt;
|ZeitraumBis= 30.04.2020&lt;br /&gt;
|Beteiligt=AIP, FH Potsdam, KIT&lt;br /&gt;
|Förderung= DFG bis 2020,  RDMO Arbeitsgemeinschaft ab 2020&lt;br /&gt;
|Website=http://rdmorganiser.github.io/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Der Research Data Management Organiser, kurz RDMO, ist ein Tool zur Erstellung von Datenmanagementplänen. Es wurde im Rahmen eines DFG-geförderten Projekts entwickelt und nun von einer RDMO-Arbeitsgemeinschaft weiter betreut, in der jeder mitarbeiten kann.&lt;br /&gt;
&lt;br /&gt;
=Einleitung=&lt;br /&gt;
Ziel des Projekts ist es, ein Werkzeug zur Verfügung zu stellen, das die strukturierte Planung, Umsetzung und Verwaltung des Forschungsdatenmanagements unterstützt und zusätzlich die textuelle Ausgabe eines Datenmanagementplans (DMP) ermöglicht. Ein Datenmanagementplan soll klären auf welche Art und Weise mit den anfallenden Forschungsdaten während, aber auch nach dem Ende eines Projekts, umgegangen werden soll. Es gilt beispielsweise zu klären in welchem Umfang Forschungsdaten anfallen, wie und wo diese gespeichert werden sollen und wer darauf zugreifen darf. Wie unter [[Data_Management_Pläne]] erklärt, gibt es bereits von verschiedenen Institutionen entwickelte Online-Tools: das Digital Curation Centre (DCC) in Großbritannien mit [http://dmponline.dcc.ac.uk DMPonline], die California Digital Library (CDL) mit dem [http://dmptool.org DMPTool] und in Deutschland das [http://data.uni-bielefeld.de/de/data-management-plan Online Tool für die Erstellung eines DMP] der Universität Bielefeld.&lt;br /&gt;
&lt;br /&gt;
=Geschichte/Entwicklung=&lt;br /&gt;
&lt;br /&gt;
==Erste Projektphase==&lt;br /&gt;
&lt;br /&gt;
Die erste Projektphase dauerte von November 2015 bis April 2017 und diente der Entwicklung von RDMO. &lt;br /&gt;
&lt;br /&gt;
Der Hauptzweck von Tools zur Erstellung von DMPs ist es, den Vorgaben des jeweiligen Förderers zu entsprechen und die einmalige Erstellung eines DMPs zu unterstützen. Das Ziel von RDMO ist jedoch eine Nutzung, die über die Antragsstellung hinausgeht. So kann das Erstellen eines DMPs die Planung des Forschungsdatenmanagements im Vorfeld optimieren und der Datenmanagementplan schließlich das ganze Projekt lang begleiten und unterstützen, in dem er als Leitfaden dient. Dies könnte die Effizienz und die Qualität der wissenschaftlichen Arbeit erhöhen und somit auch die Motivation der Forschenden solch einen DMP zu erstellen. Die Zielgruppe sind jedoch nicht nur die Forschende selbst, sondern auch alle im Forschungsdatenmanagement Involvierten. Das Tool ist für die verschiedensten Disziplinen und Institute anpassbar und einsetzbar. Das Online-Tool wird derzeit auf Deutsch und Englisch angeboten.&lt;br /&gt;
&lt;br /&gt;
==Zweite Projektphase==&lt;br /&gt;
&lt;br /&gt;
Das RDMO-Projekt befindet sich derzeit in der zweiten Pojektphase, die von November 2017 bis April 2020 läuft.&lt;br /&gt;
&lt;br /&gt;
Die Ziele für die zweite Projektphase sind insbesondere:&lt;br /&gt;
&lt;br /&gt;
*Erweiterung des Organisers: Rollenkonzept, Kostenabschätzung, Ingest-Prozess, Interoperabilität&lt;br /&gt;
&lt;br /&gt;
*Integration in die Infrastruktur: standardisierte Installation, Wartbarkeit, Ausbau der untersützten Authentifizierungs- und Autorisierungs-Systeme&lt;br /&gt;
&lt;br /&gt;
*Etablierung in der Community&lt;br /&gt;
&lt;br /&gt;
*Nachhaltigkeit / Verstetigung&lt;br /&gt;
&lt;br /&gt;
==RDMO Arbeitsgemeinschaft==&lt;br /&gt;
&lt;br /&gt;
Mit der Verabschiedung eines Memorandum of Understanding (MoU) wird das RDMO Projekt durch die RDMO Arbeitsgemeinschaft weitergeführt. &lt;br /&gt;
&lt;br /&gt;
Die RDMO Arbeitsgemeinschaft hat drei Arbeitsgruppen gebildet: Steuerungsgruppe , Softwaregruppe, Contentgruppe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Berichte==&lt;br /&gt;
&lt;br /&gt;
[[Erstes Community-Treffen|1. Community-Treffen]] (Essen, September 2018)&lt;br /&gt;
&lt;br /&gt;
[[Zweites Community-Treffen|2. Community-Treffen]] (Darmstadt, Oktober 2019)&lt;br /&gt;
&lt;br /&gt;
[[Drittes Community-Treffen|3. Community Treffen]] (Potsdam, Februar 2020)&lt;br /&gt;
&lt;br /&gt;
[[Viertes Community-Treffen|4. Community Treffen]] (Virtuell, Oktober 2020)&lt;br /&gt;
&lt;br /&gt;
[https://rdmorganiser.github.io/rdmo_arge/ MoU und RDMO Arbeitsgemeinschaft] (Virtuell, Februar 2021)&lt;br /&gt;
&lt;br /&gt;
[[Sechstes Community-Treffen|6. Community Treffen]] (Virtuell, Oktober 2021)&lt;br /&gt;
&lt;br /&gt;
=Anleitungen=&lt;br /&gt;
&lt;br /&gt;
==Dokumentation==&lt;br /&gt;
&lt;br /&gt;
Die Dokumentation für die Installation und die Einrichtung von RDMO ist unter [http://rdmo.readthedocs.io/de/latest] zu finden.&lt;br /&gt;
&lt;br /&gt;
==Tutorials==&lt;br /&gt;
&amp;lt;span id=&amp;quot;RDMOTutorials&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;&lt;br /&gt;
Tutorials für RDMO sind auf der RDMO-Webseite unter [[https://rdmorganiser.github.io/tutorials/ Tutorials]] verlinkt, wir versuchen auch untenstehende Übersicht aktuell zu halten:&lt;br /&gt;
&lt;br /&gt;
*Schnellstart-Anleitung für Nutzer [[https://rdmorganiser.github.io/docs/Schnellstartanleitung.pdf PDF]]&lt;br /&gt;
*Schnellstart-Anleitung für Administratoren [[https://rdmorganiser.github.io/docs/SchnellstartanleitungAdminsv2.pdf PDF]]&lt;br /&gt;
*[[Katalog_erstellen|&amp;quot;Wie erstelle ich einen Fragenkatalog in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Ansicht_erstellen|&amp;quot;Wie erstelle ich eine Ansicht (View) in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Bedingung_erstellen|&amp;quot;Wie erstelle ich eine Bedingung in RDMO?&amp;quot;]]&lt;br /&gt;
*[[Import_Export|&amp;quot;Wie importiere und exportiere ich XML-Dateien in RDMO?&amp;quot;]]&lt;br /&gt;
&lt;br /&gt;
==Frequently asked questions (FAQ)==&lt;br /&gt;
&lt;br /&gt;
[[RDMO_FAQ|Frequently asked questions]]&lt;br /&gt;
&lt;br /&gt;
==Verfügbares und in Vorbereitung befindliches Zubehör in der RDMO-Community==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!Institution&lt;br /&gt;
!Produkt, z.B. Fragenkatalog&lt;br /&gt;
!vor allem geeignet für&lt;br /&gt;
&lt;br /&gt;
!Benennung&amp;lt;br /&amp;gt;&lt;br /&gt;
!Ansprechpartner&lt;br /&gt;
!Status mit Link, falls verfügbar&lt;br /&gt;
!Beschreibung&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne (DMP) allgemein&lt;br /&gt;
|RDMO&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|generisch, detailliert&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Schweizer Nationalfonds&lt;br /&gt;
|SNF&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|Kurzer Fragenkatalog&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|Kurzversion des RDMO-Katalogs&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|&lt;br /&gt;
|DCC Checkliste 4.0&lt;br /&gt;
|RDMO&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/rdmorganiser/questions verfügbar]&lt;br /&gt;
|entwickelt nach DCC. (2013). Checklist for a Data Management Plan. v.4.0. Edinburgh: Digital Curation&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|RDMO&lt;br /&gt;
|Ansicht&lt;br /&gt;
|Horizon Europe&lt;br /&gt;
|&lt;br /&gt;
|RDMO&lt;br /&gt;
|in der Konzeption&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG, 1. Version des DMP&lt;br /&gt;
|DFG&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten.pdf DFG-Leitlinien zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 101 Alte Kulturen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 101 &amp;quot;Alte Kulturen&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_101_forschungsdaten.pdf Handreichung zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Projekte mit mündlichen Korpora, 1. Version des DMP&lt;br /&gt;
|DFG 104 Mündlicher Korpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, Textkorpora-Projekte, 1. Version des DMP&lt;br /&gt;
|DFG 104 Textkorpus&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-Fachkollegium 104 &amp;quot;Sprachwissenschaften&amp;quot;, [https://www.dfg.de/download/pdf/foerderung/grundlagen_dfg_foerderung/informationen_fachwissenschaften/geisteswissenschaften/standards_sprachkorpora.pdf Empfehlungen zu datentechnischen Standards und Tools bei der Erhebung von Sprachkorpora]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 105 &amp;quot;Literaturwissenschaft&amp;quot;, Editionsprojekte, 1. Version des DMP&lt;br /&gt;
|DFG 105 Edition&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf Förderkriterien für wissenschaftliche Editionen in der Literaturwissenschaft]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 106, 1. Version des DMP&lt;br /&gt;
|DFG 106 Sozial- u. Kulturanthropologie, Außereurop. Kulturen, Judaistik u. Religionswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/handreichung_fachkollegium_106_forschungsdaten.pdf Handreichung des Fachkollegiums 106 Sozial- und Kulturanthropologie, Außereuropäische Kulturen, Judaistik und Religionswissenschaft zum Umgang mit Forschungsdaten]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 109 &amp;quot;Erziehungswissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 109 Bildungswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Petra Stanat, [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_bildungsforschung.pdf Bereitstellung und Nutzung quantitativer Forschungsdaten in der Bildungsforschung: Memorandum des Fachkollegiums &amp;quot;Erziehungswissenschaft&amp;quot; der DFG]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 110 &amp;quot;Sozialwissenschaft&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 110 Sozialwiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Fachkollegium 111 &amp;quot;Wirtschaftswissenschaften&amp;quot;, 1. Version des DMP&lt;br /&gt;
|DFG 111 Wirtschaftswiss.&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach Rat für Sozial- und WirtschaftsDaten (RatSWD), [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/basisinformationen_forschungsdatenmanagement.pdf Basisinformationen zum Forschungsdatenmanagement] und [https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/fachkollegium112_forschungsdatenmanagement_de_1811.pdf Management von Forschungsdaten: Was erwartet das Fachkollegium 112 &amp;quot;Wirtschaftswissenschaften&amp;quot; von Antragstellenden?]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|DFG-Projekte in der Biodiversitätsforschung&lt;br /&gt;
|DFG Biodiversitätsforschung&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|entwickelt nach DFG-[https://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/richtlinien_forschungsdaten_biodiversitaetsforschung.pdf Richtlinien zum Umgang mit Forschungsdaten in der Biodiversitätsforschung]&lt;br /&gt;
|-&lt;br /&gt;
|FoDaKo&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Datenmanagementpläne allgemein&lt;br /&gt;
|Alle Fragen&lt;br /&gt;
|Torsten Rathmann&lt;br /&gt;
|[https://github.com/rdmorganiser/rdmo-catalog/tree/master/shared/fodako Version 4.3]&lt;br /&gt;
|RDMO-Katalog erweitert um die Fragen in den anderen FoDaKo-Katalogen&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Unterstützung bei Beratungsgesprächen&lt;br /&gt;
|UA Ruhr-Beratung&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann vor einem Beratungsgespräch zu Datenmanagementplänen oder FDM allgemein ausgefüllt werden, als Grundlage für das Gespräch.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Antragstellung&lt;br /&gt;
|UA Ruhr-Antrag&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden um das Datenmanagement für einen Antrag dokumentieren zu können.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Zur Beantragung von Speicherplatz&lt;br /&gt;
|UA Ruhr-Archiv&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|Der Katalog kann genutzt werden, wenn geplant ist die Daten in einem zentralen Speicher, Archiv oder Repositorium abzulegen.&lt;br /&gt;
|-&lt;br /&gt;
|UARuhr&lt;br /&gt;
|Fragenkatalog&lt;br /&gt;
|Forschungsdatenmanagement allgemein&lt;br /&gt;
|UA Ruhr&lt;br /&gt;
|Johannes Frenzel, Sonja Hendriks, Kathrin Höhner&lt;br /&gt;
|[https://github.com/FDM-UARuhr/rdmo-catalog-uaruhr/releases/tag/v1.0.0 Version 1.0.0]&lt;br /&gt;
|In diesem Katalog sind alle UARuhr-Fragen enthalten. Er behandelt umfassend die verschiedenen Aspekte des Forschungsdatenmanagements, deckt Anforderungen verschiedener Disziplinen ab, und ist daher recht umfangreich.&lt;br /&gt;
|-&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Weblinks==&lt;br /&gt;
&lt;br /&gt;
*RDMO-Projektwebseite: http://rdmorganiser.github.io/&lt;br /&gt;
*RDMO-GitHub Organisation und Quellcode: http://github.com/rdmorganiser&lt;br /&gt;
*RDMO-Demo-Instanz: http://rdmo.aip.de&lt;br /&gt;
&lt;br /&gt;
[[Kategorie:Projekte]]&lt;br /&gt;
[[Kategorie:Data Management]]&lt;br /&gt;
[[Kategorie:Open Science]]&lt;br /&gt;
[[Kategorie:Förderorganisationen]]&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6739</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6739"/>
		<updated>2021-11-03T10:56:03Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr [[:Datei:RDMO_StG_Report_20211004.pdf |Bericht StG]] : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Breakout Sessions===&lt;br /&gt;
Stichpunkte zur Diskussion in den Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
====RDMO in der Beratung====&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
=====Impulsvortrag Annette Strauch-Davey=====&lt;br /&gt;
&lt;br /&gt;
*Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
*Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
&lt;br /&gt;
*Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
&lt;br /&gt;
*Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
*Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
*Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
*RDMO als Forschungswerkzeug?&lt;br /&gt;
&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====RDMO zur Erstellung von DMPs====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
&lt;br /&gt;
*DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
*DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
*Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
*Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
=====Zusammenfassung:=====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Anbindung weiterer Tools im Workflow FDM====&lt;br /&gt;
Breakout 3&lt;br /&gt;
&lt;br /&gt;
*Jochen Klar: Liste von in RDMO vorhandenen API, Input/Output&lt;br /&gt;
&lt;br /&gt;
=====Nutzung von Schnittstellen=====&lt;br /&gt;
	 * UGöttingen (Ubbo Veentjer): nutzen die Postgres-Datenbank direkt fürs Monitoring (Grafana)&lt;br /&gt;
	 * MRI (Bernhard Lange) : Einbindungsmöglichkeiten in bereits vorhandene Workflows sind in Überlegung, z.B. Forschungsinformationssystem-Abfragen von RDMO &amp;amp; vice versa&lt;br /&gt;
	 * U Do (Kathrin Höhner) : Kerndatensatz Forschung (KdsF) als mögliche Schnittmenge für FIS Systeme&lt;br /&gt;
	 * Jochen Klar: Hochladen von solchen Dateien in RDMO bereits möglich, aber ein konkretes Mapping der Items muss lokal erfolgen, &lt;br /&gt;
=====zu heterogene Strukturen und Metadaten=====&lt;br /&gt;
&lt;br /&gt;
*Plugin muss auch lokal angepasst werden bei Updates&lt;br /&gt;
*RDMO Plugin-Schnittstelle werden stabil gehalten&lt;br /&gt;
*&#039;Schieben von Aufgaben&#039; (in andere Systeme)&lt;br /&gt;
&lt;br /&gt;
	 - ist bereits für GitHub + GitLab implementiert&lt;br /&gt;
&lt;br /&gt;
	 - für Jira, redmine etc. kann das erfolgen, aber ist mit Aufwand verbunden&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Glue Code:&#039;&#039;&#039; Verbindung von lokalen Anforderungen/Systemen an RDMO kann von bereits gut ausgearbeiteten Schnittstellen seitens RDMO arbeiten, aber ein &#039;deklaratives Mapping&#039; von Metadaten ist nicht immer möglich.  Daher ist Scripting an dieser Stelle die sinnvolle Herangehensweise.&lt;br /&gt;
&lt;br /&gt;
*Bei solchen lokalen Vorhaben ist ein vorhergehender Kontakt zur Software-Gruppe sehr erwünscht und sinnvoll, um optimale Nutzung und Einbindung zu gewährleisten.&lt;br /&gt;
&lt;br /&gt;
=====DOI / RoR etc. Nutzung=====&lt;br /&gt;
&lt;br /&gt;
*DataCite Schema ist in RDMO technisch möglich, muss aber noch von den Fragenkatalogen abgedeckt werden..&lt;br /&gt;
	 &lt;br /&gt;
*geprüft werden muss, wie z.B. die Fabrica-Schnittstelle von DataCite genutzt werden kann&lt;br /&gt;
&lt;br /&gt;
=====DMP Publication und maDMP:=====&lt;br /&gt;
	(U Wuppertal) Thorsten Rathmann: Wird die maDMP Nutzung nicht zu einer Verengung der DMP führen?&lt;br /&gt;
	&lt;br /&gt;
*Publikation und Vergleichbarkeit von DMP (maDMP) sind nicht so sehr eine technische Frage, da können verschiedene vorhandenen RDMO-Fähigkeiten genutzt werden.&lt;br /&gt;
*Jochen Klar: RDMO lässt den Projekte/Institutionen usw. die Entscheidungshoheit über die DMP&lt;br /&gt;
*(AIP) Harry Enke: Die Archivierung, DOI Minting usw. sind entscheidend von der Diskussion abhängig, was aus den DMP (bzw. RMDO Infos) soll denn veröffentlicht werden.&lt;br /&gt;
&lt;br /&gt;
Es ist nicht geplant DMPs direkt aus RDMO zu veröffentlichen. In der Zukunft ist es aber denkbar das eine Publikation von DMP in externen Systemen unterstützt wird.&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Datei:RDMO_StG_Report_20211004.pdf&amp;diff=6738</id>
		<title>Datei:RDMO StG Report 20211004.pdf</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Datei:RDMO_StG_Report_20211004.pdf&amp;diff=6738"/>
		<updated>2021-11-03T10:51:46Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6728</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6728"/>
		<updated>2021-10-19T16:22:26Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr Bericht StG : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Breakout Sessions ===&lt;br /&gt;
Stichpunkte zur Diskussion in den Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
==== RDMO in der Beratung ====&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
===== Impulsvortrag Annette Strauch =====&lt;br /&gt;
* Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
* Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
* Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
* Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
* Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
* Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
* RDMO als Forschungswerkzeug?&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO zur Erstellung von DMPs ====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
* DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
* DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
* Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
* Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
===== Zusammenfassung: =====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Anbindung weiterer Tools im Workflow FDM ====&lt;br /&gt;
Breakout 3&lt;br /&gt;
&lt;br /&gt;
* Jochen Klar: Liste von in RDMO vorhandenen API, Input/Output&lt;br /&gt;
&lt;br /&gt;
===== Nutzung von Schnittstellen =====&lt;br /&gt;
	 * UGöttingen (Ubbo Veentjer): nutzen die Postgres-Datenbank direkt fürs Monitoring (Grafana)&lt;br /&gt;
	 * MRI (Bernhard Lange) : Einbindungsmöglichkeiten in bereits vorhandene Workflows sind in Überlegung, z.B. Forschungsinformationssystem-Abfragen von RDMO &amp;amp; vice versa&lt;br /&gt;
	 * U Do (Kathrin Höhner) : Kerndatensatz Forschung (KdsF) als mögliche Schnittmenge für FIS Systeme&lt;br /&gt;
	 * Jochen Klar: Hochladen von solchen Dateien in RDMO bereits möglich, aber ein konkretes Mapping der Items muss lokal erfolgen, &lt;br /&gt;
===== zu heterogene Strukturen und Metadaten =====&lt;br /&gt;
* Plugin muss auch lokal angepasst werden bei Updates &lt;br /&gt;
* RDMO Plugin-Schnittstelle werden stabil gehalten&lt;br /&gt;
* &#039;Schieben von Aufgaben&#039; (in andere Systeme)&lt;br /&gt;
&lt;br /&gt;
	 - ist bereits für GitHub + GitLab implementiert&lt;br /&gt;
&lt;br /&gt;
	 - für Jira, redmine etc. kann das erfolgen, aber ist mit Aufwand verbunden&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Glue Code:&#039;&#039;&#039; Verbindung von lokalen Anforderungen/Systemen an RDMO kann von bereits gut ausgearbeiteten Schnittstellen seitens RDMO arbeiten, aber ein &#039;deklaratives Mapping&#039; von Metadaten ist nicht immer möglich.  Daher ist Scripting an dieser Stelle die sinnvolle Herangehensweise.&lt;br /&gt;
*	 Bei solchen lokalen Vorhaben ist ein vorhergehender Kontakt zur Software-Gruppe sehr erwünscht und sinnvoll, um optimale Nutzung und Einbindung zu gewährleisten.&lt;br /&gt;
&lt;br /&gt;
===== DOI / RoR etc. Nutzung =====&lt;br /&gt;
* DataCite Schema ist in RDMO technisch möglich, muss aber noch von den Fragenkatalogen abgedeckt werden..&lt;br /&gt;
	 &lt;br /&gt;
* geprüft werden muss, wie z.B. die Fabrica-Schnittstelle von DataCite genutzt werden kann&lt;br /&gt;
&lt;br /&gt;
===== DMP Publication und maDMP: =====&lt;br /&gt;
	(U Wuppertal) Thorsten Rathmann: Wird die maDMP Nutzung nicht zu einer Verengung der DMP führen?&lt;br /&gt;
	&lt;br /&gt;
* Publikation und Vergleichbarkeit von DMP (maDMP) sind nicht so sehr eine technische Frage, da können verschiedene vorhandenen RDMO-Fähigkeiten genutzt werden.&lt;br /&gt;
* Jochen Klar: RDMO lässt den Projekte/Institutionen usw. die Entscheidungshoheit über die DMP &lt;br /&gt;
* (AIP) Harry Enke: Die Archivierung, DOI Minting usw. sind entscheidend von der Diskussion abhängig, was aus den DMP (bzw. RMDO Infos) soll denn veröffentlicht werden.&lt;br /&gt;
&lt;br /&gt;
Es ist nicht geplant DMPs direkt aus RDMO zu veröffentlichen. In der Zukunft ist es aber denkbar das eine Publikation von DMP in externen Systemen unterstützt wird.&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6727</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6727"/>
		<updated>2021-10-19T16:18:14Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Breakout Sessions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr Bericht StG : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Breakout Sessions&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== RDMO in der Beratung ====&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
===== Impulsvortrag Annette Strauch =====&lt;br /&gt;
* Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
* Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
* Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
* Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
* Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
* Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
* RDMO als Forschungswerkzeug?&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO zur Erstellung von DMPs ====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
* DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
* DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
* Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
* Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
===== Zusammenfassung: =====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Anbindung weiterer Tools im Workflow FDM ====&lt;br /&gt;
Breakout 3&lt;br /&gt;
&lt;br /&gt;
* Jochen Klar: Liste von in RDMO vorhandenen API, Input/Output&lt;br /&gt;
&lt;br /&gt;
===== Nutzung von Schnittstellen =====&lt;br /&gt;
	 * UGöttingen (Ubbo Veentjer): nutzen die Postgres-Datenbank direkt fürs Monitoring (Grafana)&lt;br /&gt;
	 * MRI (Bernhard Lange) : Einbindungsmöglichkeiten in bereits vorhandene Workflows sind in Überlegung, z.B. Forschungsinformationssystem-Abfragen von RDMO &amp;amp; vice versa&lt;br /&gt;
	 * U Do (Kathrin Höhner) : Kerndatensatz Forschung (KdsF) als mögliche Schnittmenge für FIS Systeme&lt;br /&gt;
	 * Jochen Klar: Hochladen von solchen Dateien in RDMO bereits möglich, aber ein konkretes Mapping der Items muss lokal erfolgen, &lt;br /&gt;
===== zu heterogene Strukturen und Metadaten =====&lt;br /&gt;
* Plugin muss auch lokal angepasst werden bei Updates &lt;br /&gt;
* RDMO Plugin-Schnittstelle werden stabil gehalten&lt;br /&gt;
* &#039;Schieben von Aufgaben&#039; (in andere Systeme)&lt;br /&gt;
&lt;br /&gt;
	 - ist bereits für GitHub + GitLab implementiert&lt;br /&gt;
&lt;br /&gt;
	 - für Jira, redmine etc. kann das erfolgen, aber ist mit Aufwand verbunden&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Glue Code:&#039;&#039;&#039; Verbindung von lokalen Anforderungen/Systemen an RDMO kann von bereits gut ausgearbeiteten Schnittstellen seitens RDMO arbeiten, aber ein &#039;deklaratives Mapping&#039; von Metadaten ist nicht immer möglich.  Daher ist Scripting an dieser Stelle die sinnvolle Herangehensweise.&lt;br /&gt;
*	 Bei solchen lokalen Vorhaben ist ein vorhergehender Kontakt zur Software-Gruppe sehr erwünscht und sinnvoll, um optimale Nutzung und Einbindung zu gewährleisten.&lt;br /&gt;
&lt;br /&gt;
===== DOI / RoR etc. Nutzung =====&lt;br /&gt;
* DataCite Schema ist in RDMO technisch möglich, muss aber noch von den Fragenkatalogen abgedeckt werden..&lt;br /&gt;
	 &lt;br /&gt;
* geprüft werden muss, wie z.B. die Fabrica-Schnittstelle von DataCite genutzt werden kann&lt;br /&gt;
&lt;br /&gt;
===== DMP Publication und maDMP: =====&lt;br /&gt;
	(U Wuppertal) Thorsten Rathmann: Wird die maDMP Nutzung nicht zu einer Verengung der DMP führen?&lt;br /&gt;
	&lt;br /&gt;
* Publikation und Vergleichbarkeit von DMP (maDMP) sind nicht so sehr eine technische Frage, da können verschiedene vorhandenen RDMO-Fähigkeiten genutzt werden.&lt;br /&gt;
* Jochen Klar: RDMO lässt den Projekte/Institutionen usw. die Entscheidungshoheit über die DMP &lt;br /&gt;
* (AIP) Harry Enke: Die Archivierung, DOI Minting usw. sind entscheidend von der Diskussion abhängig, was aus den DMP (bzw. RMDO Infos) soll denn veröffentlicht werden.&lt;br /&gt;
&lt;br /&gt;
Es ist nicht geplant DMPs direkt aus RDMO zu veröffentlichen. In der Zukunft ist es aber denkbar das eine Publikation von DMP in externen Systemen unterstützt wird.&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6726</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6726"/>
		<updated>2021-10-19T16:14:15Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Intro */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr Bericht StG : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Breakout Sessions ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO in der Beratung ====&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
===== Impulsvortrag Annette Strauch =====&lt;br /&gt;
* Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
* Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
* Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
* Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
* Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
* Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
* RDMO als Forschungswerkzeug?&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO zur Erstellung von DMPs ====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
* DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
* DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
* Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
* Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
===== Zusammenfassung: =====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Anbindung weiterer Tools im Workflow FDM ====&lt;br /&gt;
Breakout 3&lt;br /&gt;
&lt;br /&gt;
* Jochen Klar: Liste von in RDMO vorhandenen API, Input/Output&lt;br /&gt;
&lt;br /&gt;
===== Nutzung von Schnittstellen =====&lt;br /&gt;
	 * UGöttingen (Ubbo Veentjer): nutzen die Postgres-Datenbank direkt fürs Monitoring (Grafana)&lt;br /&gt;
	 * MRI (Bernhard Lange) : Einbindungsmöglichkeiten in bereits vorhandene Workflows sind in Überlegung, z.B. Forschungsinformationssystem-Abfragen von RDMO &amp;amp; vice versa&lt;br /&gt;
	 * U Do (Kathrin Höhner) : Kerndatensatz Forschung (KdsF) als mögliche Schnittmenge für FIS Systeme&lt;br /&gt;
	 * Jochen Klar: Hochladen von solchen Dateien in RDMO bereits möglich, aber ein konkretes Mapping der Items muss lokal erfolgen, &lt;br /&gt;
===== zu heterogene Strukturen und Metadaten =====&lt;br /&gt;
* Plugin muss auch lokal angepasst werden bei Updates &lt;br /&gt;
* RDMO Plugin-Schnittstelle werden stabil gehalten&lt;br /&gt;
* &#039;Schieben von Aufgaben&#039; (in andere Systeme)&lt;br /&gt;
&lt;br /&gt;
	 - ist bereits für GitHub + GitLab implementiert&lt;br /&gt;
&lt;br /&gt;
	 - für Jira, redmine etc. kann das erfolgen, aber ist mit Aufwand verbunden&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Glue Code:&#039;&#039;&#039; Verbindung von lokalen Anforderungen/Systemen an RDMO kann von bereits gut ausgearbeiteten Schnittstellen seitens RDMO arbeiten, aber ein &#039;deklaratives Mapping&#039; von Metadaten ist nicht immer möglich.  Daher ist Scripting an dieser Stelle die sinnvolle Herangehensweise.&lt;br /&gt;
*	 Bei solchen lokalen Vorhaben ist ein vorhergehender Kontakt zur Software-Gruppe sehr erwünscht und sinnvoll, um optimale Nutzung und Einbindung zu gewährleisten.&lt;br /&gt;
&lt;br /&gt;
===== DOI / RoR etc. Nutzung =====&lt;br /&gt;
* DataCite Schema ist in RDMO technisch möglich, muss aber noch von den Fragenkatalogen abgedeckt werden..&lt;br /&gt;
	 &lt;br /&gt;
* geprüft werden muss, wie z.B. die Fabrica-Schnittstelle von DataCite genutzt werden kann&lt;br /&gt;
&lt;br /&gt;
===== DMP Publication und maDMP: =====&lt;br /&gt;
	(U Wuppertal) Thorsten Rathmann: Wird die maDMP Nutzung nicht zu einer Verengung der DMP führen?&lt;br /&gt;
	&lt;br /&gt;
* Publikation und Vergleichbarkeit von DMP (maDMP) sind nicht so sehr eine technische Frage, da können verschiedene vorhandenen RDMO-Fähigkeiten genutzt werden.&lt;br /&gt;
* Jochen Klar: RDMO lässt den Projekte/Institutionen usw. die Entscheidungshoheit über die DMP &lt;br /&gt;
* (AIP) Harry Enke: Die Archivierung, DOI Minting usw. sind entscheidend von der Diskussion abhängig, was aus den DMP (bzw. RMDO Infos) soll denn veröffentlicht werden.&lt;br /&gt;
&lt;br /&gt;
Es ist nicht geplant DMPs direkt aus RDMO zu veröffentlichen. In der Zukunft ist es aber denkbar das eine Publikation von DMP in externen Systemen unterstützt wird.&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6725</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6725"/>
		<updated>2021-10-19T16:13:33Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Anbindung weiterer Tools im Workflow FDM */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr Bericht StG : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Breakout Sessions ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO in der Beratung ====&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
===== Impulsvortrag Annette Strauch =====&lt;br /&gt;
* Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
* Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
* Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
* Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
* Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
* Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
* RDMO als Forschungswerkzeug?&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO zur Erstellung von DMPs ====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
* DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
* DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
* Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
* Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
===== Zusammenfassung: =====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Anbindung weiterer Tools im Workflow FDM ====&lt;br /&gt;
Breakout 3&lt;br /&gt;
&lt;br /&gt;
===== Intro =====&lt;br /&gt;
 Jochen Klar: Liste von in RDMO vorhandenen API, Input/Output&lt;br /&gt;
&lt;br /&gt;
===== Nutzung von Schnittstellen =====&lt;br /&gt;
	 * UGöttingen (Ubbo Veentjer): nutzen die Postgres-Datenbank direkt fürs Monitoring (Grafana)&lt;br /&gt;
	 * MRI (Bernhard Lange) : Einbindungsmöglichkeiten in bereits vorhandene Workflows sind in Überlegung, z.B. Forschungsinformationssystem-Abfragen von RDMO &amp;amp; vice versa&lt;br /&gt;
	 * U Do (Kathrin Höhner) : Kerndatensatz Forschung (KdsF) als mögliche Schnittmenge für FIS Systeme&lt;br /&gt;
	 * Jochen Klar: Hochladen von solchen Dateien in RDMO bereits möglich, aber ein konkretes Mapping der Items muss lokal erfolgen, &lt;br /&gt;
===== zu heterogene Strukturen und Metadaten =====&lt;br /&gt;
* Plugin muss auch lokal angepasst werden bei Updates &lt;br /&gt;
* RDMO Plugin-Schnittstelle werden stabil gehalten&lt;br /&gt;
* &#039;Schieben von Aufgaben&#039; (in andere Systeme)&lt;br /&gt;
&lt;br /&gt;
	 - ist bereits für GitHub + GitLab implementiert&lt;br /&gt;
&lt;br /&gt;
	 - für Jira, redmine etc. kann das erfolgen, aber ist mit Aufwand verbunden&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Glue Code:&#039;&#039;&#039; Verbindung von lokalen Anforderungen/Systemen an RDMO kann von bereits gut ausgearbeiteten Schnittstellen seitens RDMO arbeiten, aber ein &#039;deklaratives Mapping&#039; von Metadaten ist nicht immer möglich.  Daher ist Scripting an dieser Stelle die sinnvolle Herangehensweise.&lt;br /&gt;
*	 Bei solchen lokalen Vorhaben ist ein vorhergehender Kontakt zur Software-Gruppe sehr erwünscht und sinnvoll, um optimale Nutzung und Einbindung zu gewährleisten.&lt;br /&gt;
&lt;br /&gt;
===== DOI / RoR etc. Nutzung =====&lt;br /&gt;
* DataCite Schema ist in RDMO technisch möglich, muss aber noch von den Fragenkatalogen abgedeckt werden..&lt;br /&gt;
	 &lt;br /&gt;
* geprüft werden muss, wie z.B. die Fabrica-Schnittstelle von DataCite genutzt werden kann&lt;br /&gt;
&lt;br /&gt;
===== DMP Publication und maDMP: =====&lt;br /&gt;
	(U Wuppertal) Thorsten Rathmann: Wird die maDMP Nutzung nicht zu einer Verengung der DMP führen?&lt;br /&gt;
	&lt;br /&gt;
* Publikation und Vergleichbarkeit von DMP (maDMP) sind nicht so sehr eine technische Frage, da können verschiedene vorhandenen RDMO-Fähigkeiten genutzt werden.&lt;br /&gt;
* Jochen Klar: RDMO lässt den Projekte/Institutionen usw. die Entscheidungshoheit über die DMP &lt;br /&gt;
* (AIP) Harry Enke: Die Archivierung, DOI Minting usw. sind entscheidend von der Diskussion abhängig, was aus den DMP (bzw. RMDO Infos) soll denn veröffentlicht werden.&lt;br /&gt;
&lt;br /&gt;
Es ist nicht geplant DMPs direkt aus RDMO zu veröffentlichen. In der Zukunft ist es aber denkbar das eine Publikation von DMP in externen Systemen unterstützt wird.&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6724</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6724"/>
		<updated>2021-10-19T16:12:20Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Anbindung weiterer Tools im Workflow FDM */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr Bericht StG : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Breakout Sessions ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO in der Beratung ====&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
===== Impulsvortrag Annette Strauch =====&lt;br /&gt;
* Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
* Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
* Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
* Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
* Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
* Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
* RDMO als Forschungswerkzeug?&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO zur Erstellung von DMPs ====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
* DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
* DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
* Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
* Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
===== Zusammenfassung: =====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Anbindung weiterer Tools im Workflow FDM ====&lt;br /&gt;
Breakout 3&lt;br /&gt;
&lt;br /&gt;
===== Intro =====&lt;br /&gt;
 Jochen Klar: Liste von in RDMO vorhandenen API, Input/Output&lt;br /&gt;
&lt;br /&gt;
===== Nutzung von Schnittstellen =====&lt;br /&gt;
	 * UGöttingen (Ubbo Veentjer): nutzen die Postgres-Datenbank direkt fürs Monitoring (Grafana)&lt;br /&gt;
	 * MRI (Bernhard Lange) : Einbindungsmöglichkeiten in bereits vorhandene Workflows sind in Überlegung, z.B. Forschungsinformationssystem-Abfragen von RDMO &amp;amp; vice versa&lt;br /&gt;
	 * U Do (Kathrin Höhner) : Kerndatensatz Forschung (KdsF) als mögliche Schnittmenge für FIS Systeme&lt;br /&gt;
	 * Jochen Klar: Hochladen von solchen Dateien in RDMO bereits möglich, aber ein konkretes Mapping der Items muss lokal erfolgen, &lt;br /&gt;
===== zu heterogene Strukturen und Metadaten =====&lt;br /&gt;
* Plugin muss auch lokal angepasst werden bei Updates &lt;br /&gt;
* RDMO Plugin-Schnittstelle werden stabil gehalten&lt;br /&gt;
* &#039;Schieben von Aufgaben&#039; (in andere Systeme)&lt;br /&gt;
&lt;br /&gt;
	 - ist bereits für GitHub + GitLab implementiert&lt;br /&gt;
&lt;br /&gt;
	 - für Jira, redmine etc. kann das erfolgen, aber ist mit Aufwand verbunden&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Glue Code:&#039;&#039;&#039; Verbindung von lokalen Anforderungen/Systemen an RDMO kann von bereits gut ausgearbeiteten Schnittstellen seitens RDMO arbeiten, aber ein &#039;deklaratives Mapping&#039; von Metadaten ist nicht immer möglich.  Daher ist Scripting an dieser Stelle die sinnvolle Herangehensweise.&lt;br /&gt;
*	 Bei solchen lokalen Vorhaben ist ein vorhergehender Kontakt zur Software-Gruppe sehr erwünscht und sinnvoll, um optimale Nutzung und Einbindung zu gewährleisten.&lt;br /&gt;
&lt;br /&gt;
 ===== DOI / RoR etc. Nutzung =====&lt;br /&gt;
* DataCite Schema ist in RDMO technisch möglich, muss aber noch von den Fragenkatalogen abgedeckt werden..&lt;br /&gt;
	 &lt;br /&gt;
- geprüft werden muss, wie z.B. die Fabrica-Schnittstelle von DataCite genutzt werden kann&lt;br /&gt;
&lt;br /&gt;
===== DMP Publication und maDMP: =====&lt;br /&gt;
	(U Wuppertal) Thorsten Rathmann: Wird die maDMP Nutzung nicht zu einer Verengung der DMP führen?&lt;br /&gt;
	&lt;br /&gt;
* Publikation und Vergleichbarkeit von DMP (maDMP) sind nicht so sehr eine technische Frage, da können verschiedene vorhandenen RDMO-Fähigkeiten genutzt werden.&lt;br /&gt;
* Jochen Klar: RDMO lässt den Projekte/Institutionen usw. die Entscheidungshoheit über die DMP &lt;br /&gt;
* (AIP) Harry Enke: Die Archivierung, DOI Minting usw. sind entscheidend von der Diskussion abhängig, was aus den DMP (bzw. RMDO Infos) soll denn veröffentlicht werden.&lt;br /&gt;
&lt;br /&gt;
Es ist nicht geplant DMPs direkt aus RDMO zu veröffentlichen. In der Zukunft ist es aber denkbar das eine Publikation von DMP in externen Systemen unterstützt wird.&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6723</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6723"/>
		<updated>2021-10-19T16:09:17Z</updated>

		<summary type="html">&lt;p&gt;Harry: /* Breakout Sessions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr Bericht StG : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Breakout Sessions ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO in der Beratung ====&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
===== Impulsvortrag Annette Strauch =====&lt;br /&gt;
* Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
* Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
* Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
* Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
* Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
* Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
* RDMO als Forschungswerkzeug?&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO zur Erstellung von DMPs ====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
* DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
* DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
* Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
* Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
===== Zusammenfassung: =====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Anbindung weiterer Tools im Workflow FDM ====&lt;br /&gt;
Breakout 3&lt;br /&gt;
&lt;br /&gt;
Intro &lt;br /&gt;
	Jochen Klar: Liste von in RDMO vorhandenen API, Input/Output&lt;br /&gt;
&lt;br /&gt;
Nutzung von Schnittstellen:&lt;br /&gt;
	 * UGöttingen (Ubbo Veentjer): nutzen die Postgres-Datenbank direkt fürs Monitoring (Grafana)&lt;br /&gt;
	 * MRI (Bernhard Lange) : Einbindungsmöglichkeiten in bereits vorhandene Workflows sind in Überlegung, z.B. Forschungsinformationssystem-Abfragen von RDMO &amp;amp; vice versa&lt;br /&gt;
	 * U Do (Kathrin Höhner) : Kerndatensatz Forschung (KdsF) als mögliche Schnittmenge für FIS Systeme&lt;br /&gt;
	 * Jochen Klar: Hochladen von solchen Dateien in RDMO bereits möglich, aber ein konkretes Mapping der Items muss lokal erfolgen, &lt;br /&gt;
zu heterogene Strukturen und Metadaten  &lt;br /&gt;
	 Plugin muss auch lokal angepasst werden bei Updates &lt;br /&gt;
 RDMO Plugin-Schnittstelle werden stabil gehalten&lt;br /&gt;
 &#039;Schieben von Aufgaben&#039; (in andere Systeme)&lt;br /&gt;
	 - ist bereits für GitHub + GitLab implementiert&lt;br /&gt;
	 - für Jira, redmine etc. kann das erfolgen, aber ist mit Aufwand verbunden&lt;br /&gt;
&lt;br /&gt;
Glue Code: Verbindung von lokalen Anforderungen/Systemen an RDMO kann von bereits gut ausgearbeiteten Schnittstellen seitens RDMO arbeiten, aber ein &#039;deklaratives Mapping&#039; von Metadaten ist nicht immer möglich.  Daher ist Scripting an dieser Stelle die sinnvolle Herangehensweise.&lt;br /&gt;
	 Bei solchen lokalen Vorhaben ist ein vorhergehender Kontakt zur Software-Gruppe sehr erwünscht und sinnvoll, um optimale Nutzung und Einbindung zu gewährleisten.&lt;br /&gt;
&lt;br /&gt;
 DOI / RoR etc. Nutzung: DataCite Schema ist in RDMO technisch möglich, muss aber noch von den Fragenkatalogen abgedeckt werden..&lt;br /&gt;
	 - geprüft werden muss, wie z.B. die Fabrica-Schnittstelle von DataCite genutzt werden kann&lt;br /&gt;
&lt;br /&gt;
DMP Publication und maDMP:&lt;br /&gt;
	(U Wuppertal) Thorsten Rathmann: Wird die maDMP Nutzung nicht zu einer Verengung der DMP führen?&lt;br /&gt;
	&lt;br /&gt;
Publikation und Vergleichbarkeit von DMP (maDMP) sind nicht so sehr eine technische Frage, da können verschiedene vorhandenen RDMO-Fähigkeiten genutzt werden.&lt;br /&gt;
	Jochen Klar: RDMO lässt den Projekte/Institutionen usw. die Entscheidungshoheit über die DMP &lt;br /&gt;
	(AIP) Harry Enke: Die Archivierung, DOI Minting usw. sind entscheidend von der Diskussion abhängig, was aus den DMP (bzw. RMDO Infos) soll denn veröffentlicht werden.&lt;br /&gt;
&lt;br /&gt;
Es ist nicht geplant DMPs direkt aus RDMO zu veröffentlichen. In der Zukunft ist es aber denkbar das eine Publikation von DMP in externen Systemen unterstützt wird.&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
	<entry>
		<id>https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6722</id>
		<title>Sechstes Community-Treffen</title>
		<link rel="alternate" type="text/html" href="https://www.forschungsdaten.org/index.php?title=Sechstes_Community-Treffen&amp;diff=6722"/>
		<updated>2021-10-19T16:06:45Z</updated>

		<summary type="html">&lt;p&gt;Harry: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
===Programm des Workshops=== &lt;br /&gt;
&lt;br /&gt;
09:00 Uhr Begrüßung (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
09:15 Uhr Bericht StG : ein Jahr Manifest - was ist geschehen? (Harry Enke)&lt;br /&gt;
&lt;br /&gt;
09:25 Uhr Bericht Software Gruppe : Software Entwicklungen (Jochen Klar)&lt;br /&gt;
&lt;br /&gt;
09:40 Uhr Bericht Content Gruppe : Horizon Europe, Externe Fragenkatalog-Integration, Templates (Thorsten Rathmann, Giacomo Lanza, Yvonne Anders)&lt;br /&gt;
&lt;br /&gt;
09:55 Uhr DMPs in der NFDI (Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
10:05 Uhr Kurze Pause&lt;br /&gt;
&lt;br /&gt;
10:15 Uhr Diskussion: Status und Perspektiven&lt;br /&gt;
&lt;br /&gt;
10:35 Uhr Organisation Breakout Session&lt;br /&gt;
10:40 Uhr Breakouts: RDMO Best Practices von RDMO Anwendern&lt;br /&gt;
&lt;br /&gt;
BreakOut I: Beratungsarbeit mit RDMO (Mod.: Daniela Hausen)&lt;br /&gt;
&lt;br /&gt;
BreakOut II: Tool zur Erstellung von Datenmanagementplänen für Förderer und Projekte (Mod.: Birte Lindstädt)&lt;br /&gt;
&lt;br /&gt;
BreakOut III: Schnittstelle für Infos zur Registrierung von DOI und ander API Nutzung (Mod.: Harry Enke)&lt;br /&gt;
&lt;br /&gt;
11:45 Uhr Zusammenfassung und Fragen aus den einzelnen Breakout Sessions&lt;br /&gt;
&lt;br /&gt;
12:15 Uhr Ende&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Breakout Sessions ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039; RDMO in der Beratung &#039;&#039;&#039;&lt;br /&gt;
Breakout 1	 	 	 	&lt;br /&gt;
&lt;br /&gt;
===== Impulsvortrag Annette Strauch =====&lt;br /&gt;
* Beratungen: sukzessives hinführen auf Thema DMPs, Tools erst, wenn &amp;quot;DMP&amp;quot; verstanden wurde&lt;br /&gt;
* Einsatz spezifischer Kataloge (Kurzer rdmo-Katalog, DFG Kataloge für zwei Fachbereiche) für Anträge&lt;br /&gt;
		- Wichtig für Wissenschaftler in der Antragstellung: DMP nicht zu lang&lt;br /&gt;
* Integration in Schulungen (Einstieg in FDM)&lt;br /&gt;
&lt;br /&gt;
Fragen / Diskussion&lt;br /&gt;
* Motivation von Wissenschaftlerin DMP ohne Vorgaben durch Förderer zu erarbeiten?&lt;br /&gt;
		- Jungen Wissenschaftlern ist das Thema Datenmanagement wichtig und kaum Motivation nötig. Ein Grund DFG-Kodex.&lt;br /&gt;
&lt;br /&gt;
		- Angebote auf Website und monatliche (bilaterale) Treffen mit Wissenschaftlern&lt;br /&gt;
&lt;br /&gt;
* Anregung Best Practices: Forscher lernen an Beispiel DMPs ?? Bereitstellung von Beispiel DMPs für RDMO?&lt;br /&gt;
&lt;br /&gt;
* Ist RDMO Tool für (alle) Wissenschaftler?&lt;br /&gt;
		- In SFB braucht es für RDMO Koordination/DataSteward (INF Projekt)&lt;br /&gt;
&lt;br /&gt;
		- Im (Vor)Antrag (z.B. DFG) oft kein Platz für FDM, wenn Geld da dann oft kein &amp;quot;Antrieb&amp;quot; mehr da, einen DMP auszufüllen&lt;br /&gt;
&lt;br /&gt;
		- Beratung sollte Vorteile eines lebenden DMPs kommunizieren: z.B. als Leitfaden für die Infrastruktur in der Institution (Forschungsförderung, Speicherangebote und weitere Angebote ?&lt;br /&gt;
&lt;br /&gt;
* RDMO als Forschungswerkzeug?&lt;br /&gt;
		- Wird optional bleiben&lt;br /&gt;
&lt;br /&gt;
		- Forcierung eher durch formale Vorgänge, Projektübergabe, Policy-Vorgaben, Ressourcenvergabe&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== RDMO zur Erstellung von DMPs ====&lt;br /&gt;
Breakout 2&lt;br /&gt;
&lt;br /&gt;
Es gibt keinen Impulsvortrag, daher eine kurze Darstellung jedes Teilnehmenden zum Thema. &lt;br /&gt;
&lt;br /&gt;
Dabei stellen sich folgende Erfahrungen heraus:&lt;br /&gt;
* DMPs sind aufgrund von Drittmittelanträgen vermehrt Thema. &lt;br /&gt;
&lt;br /&gt;
* DMPs müssen jedoch aktiv beworben/begleitet werden, um einen Mehrwert zu haben. Es muss einen Verantwortlichen im Projekt für den DMP geben. Beispielsweise ist die Vorbereitung und Durchführung der Interviews sehr aufwendig, insbesondere wenn das Projekt in Teilprojekte gegliedert ist, für die Interviews durchgeführt werden.&lt;br /&gt;
&lt;br /&gt;
* Der Aufwand ist besonders hoch, wenn ein fachspezifischer Fragenkatalog erarbeitet werden soll.&lt;br /&gt;
&lt;br /&gt;
* Die Anforderung wird erhoben, dass DMP-Tools und Projektmanagement-Tools kompatibel/verknüpfbar sein sollten, um doppelte Arbeit zu ersparen. Alles in einem Tool zu bündeln wäre gut. RDMO als Projektmanagement-Tool? RDMO bietet zumindest die technischen Möglichkeiten, das umzusetzen. Im Bereich Metadaten ist mit Blick auf DataCite schon eine Verbindung/Verknüpfung möglich.&lt;br /&gt;
&lt;br /&gt;
Frage: Einschränkung der Antwortmöglichkeiten durch maDMP (Actionable-DMP?? Wird RDMO dadurch zu einem Spezialtool für wenige Standardfälle? &lt;br /&gt;
&lt;br /&gt;
Antwort wird im Plenum gegeben: Die Inhalte des DMP sind weiterhin den Erstellern in den Projekten überlassen. Eine Einengung auf wenige Fragen/Attribute ist nicht geplant, nur die Kompatibilität mit maDMP.&lt;br /&gt;
&lt;br /&gt;
===== Zusammenfassung: =====&lt;br /&gt;
&lt;br /&gt;
Vertreter von zentralen FDM-Einrichtungen haben noch Schwierigkeiten, tatsächliche Unterstützung zu bieten. In einem konkreten Projekt ist man als Datenmanager stärker ins Projekt integriert und kann daher besser unterstützen. Die Zeitersparnis wird oftmals noch nicht deutlich. Die Vorstrukturierung durch die Fragenkataloge wird als Vorteil gesehen. Alles, was noch nicht zum Standard-Fragenkatalog gehört und händisch gemacht werden muss, wird als kompliziert eingeschätzt.  Es besteht der Wunsch RDMO direkt als Projekmanagement-Tool nutzen zu können oder zumindest eine Verbindung zu schaffen, um doppelte Arbeit zu vermeiden. Führt zur Beschränkung der Antwortmöglichkeiten? Ist das vor dem Hintergrund fachspezifischer Fragenkataloge, die erarbeitet werden sollen, sinnvoll?&lt;br /&gt;
&lt;br /&gt;
Die Diskussion wurde auf einem Pad dokumentiert: https://drive.google.com/file/d/1hKtDafi6QoQ98d2zk9VGipu8UEhjP58r/view?usp=sharing&lt;/div&gt;</summary>
		<author><name>Harry</name></author>
	</entry>
</feed>