Siebtes Community-Treffen: Unterschied zwischen den Versionen

Aus Forschungsdaten.org
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
K (Harry verschob die Seite Siebtes Communitytreffen nach Siebtes Community-Treffen)
 
(15 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 85: Zeile 85:
<br />
<br />


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


- Ausbau des Entwicklerpools
- Ausbau des Entwicklerpools
Zeile 100: Zeile 100:
-- erhöht Tranparenz der Prozesse   
-- erhöht Tranparenz der Prozesse   


* Erste Entwicklungswünsche  
*Erste Entwicklungswünsche


- Verbessertes User-Interface
- Verbessertes User-Interface
Zeile 122: Zeile 122:
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP)  
-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP)  


* Abschluss  
*Abschluss


Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?
Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?
Zeile 132: Zeile 132:
- 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.
- 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.


[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|center]]


====Notizen zum RDMO-Treffen Breakout-Raum 2====


#Einzelne Notizen zum RDMO-Treffen Raum 2
=====Technik / Software=====


##Technische Dimension
*[[Datei:C05296f20b96fd93af8f5f537.png|rahmenlos|600x600px|alternativtext=|rechts]]Drei Punkte vorneweg für die Diskussion:
**Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.
**Content ist meist drängender als Technik
**Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?
**Das "wer" ist dann der nächste Schritt.


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


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


*Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.
*Gibt es schon FIS/CRIS, die mit RDMO verbunden sind
*Content ist meist drängender als Technik
**Das ist prinzipiell über Plugins möglich, aber bis alle FIS ein Austauschformat / eine Austausch-Schnittstelle haben, wird es für viele FIS eigene Plugins brauchen.
*Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?
*Das "wer" ist dann der nächste Schritt.


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


Entscheiden nicht die Institution, die Ressourcen in die Programmierung  steckt, was gemacht wird?
*Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.
-- Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)
**Wie ist der Workflow für Requests in GitHub?
-- 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.
*Was sind Roadmaps in anderen Open Source Projekten?
-- Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)
**Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.


=====Content-Teil=====


- Modularität von RDMO
*Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken?
-- die Plugins sind ein wichtiger Schritt in diese Richtung
**Das ist sinnvoll und besonders wichtig für die Transparenz.


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


- Gibt es Entwicklungs-Guidelines?
*Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben 
-- Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.  
**Basale Informationen (Förderer,...) sollten als "Projektmetadaten" hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben.


- Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.
*Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?
*Stellt Github hier eine Barriere da?
*Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?
**Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.
**Die GitHub-Wiki-Funktion könnte auf dem RDMO-GitHub für eine Kommunikation und zum Ablegen von textuell festgehaltenen Ideen (abseits von Issues) genutzt werden.
**Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.
**Grundsätzlich verschiedenen Wege zur Kommunikation anbieten
*Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?
*Notsituation "DMP wird schnell benötigt" nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.


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


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


====Notizen zu RDMO Breakout-Raum 1====


 
=====Content-Teil=====
 
- open development ok:[[Datei:C05296f20b96fd93af8f5f536.png|Breakout room input collection|alternativtext=|rahmenlos|600x600px|rechts]]
##Inhalte - Teil 2
 
###Punkte:
 
- Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...)  abdecken?
-- Das ist sinnvoll und besonders wichtig für die Transparenz.
 
- Zu Templates von Projekten die schon vorausgefüllt sind: Es gibt schon die (programmatische) Eltern-Kind-Funktion in Projekten. Hier konnen bereits Informationen übernommen werden. Wäre das eine lösung?
 
- Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben
-- Basale Informationen (Förderer,...) sollten als "Projektmetadaten" hinterlegt werden, die Fragenkataloge können  dann die Daten beschreiben. 
 
- Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?
-- Stellt Github hier eine Barriere da?
-- Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?
-- Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.
-- Die GitHub-Wiki-Funktion könnte auf dem RDMO-GitHub für eine Kommunikation und zum Ablegen von textuell festgehaltenen Ideen (abseits von Issues) genutzt werden.
-- Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.
-- Grundsätzlich verschiedenen Wege zur Kommunikation anbieten
 
- Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?
 
- Notsituation "DMP wird schnell benötigt" nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.
 
 
 
#Einzelne Notizen zu Raum 1
 
##Content-Teil
 
- open development ok:
         Templates für Datenstrukturen  
         Templates für Datenstrukturen  
         Clonen von Datensätzen  
         Clonen von Datensätzen  
Zeile 215: Zeile 200:
- “Expertenhilfe” organisieren ?
- “Expertenhilfe” organisieren ?
   ‘zuweisen’ von Fragen an Experten ?  
   ‘zuweisen’ von Fragen an Experten ?  
- 20-30 Kataloge bei Mandanten-Version (übersicht)
- 20-30 Kataloge bei Mandanten-Version (übersicht)  
- Statistiken … horizon / DFG template
- Sammlung der Kataloge ( )  


![Input Collection 2](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f536.png)
- Statistiken … horizon / DFG template


- Sammlung der Kataloge ( ) 


##Technik/Software
=====Technik/Software=====


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


Entwicklungsprozess muss Mittel und Bedarfe matchen


Issues / Features Diskussion evtl. regelmässig organisieren
=> Entwicklungsprozess muss Mittel und Bedarfe matchen
Label für Issues um Prozess/Diskussion transparenter zu machen  
        Issues / Features Diskussion evtl. regelmässig organisieren  
        Label für Issues um Prozess/Diskussion transparenter zu machen  


=> mehrere Entwickler benötigt:  
=> mehrere Entwickler benötigt:  
Crash-Course RDMO development?  
 
Einführungskurs (JK) evtl. wiederholen  
        Crash-Course RDMO development?  
Plugin Entwicklung
        Einführungskurs (JK) evtl. wiederholen  
 
=> Plugin Entwicklung
   
   
=> Hereinnahme von anderen   Funktionen als DMP Produktion
 
         Schnittstellen zu anderen Systemen
=> Hereinnahme von anderen Funktionen als DMP Produktion
         Schnittstellen zu anderen Systemen
         Software management
         Software management
Projektmanagement ?
Projektmanagement ?


Zeile 251: Zeile 239:
         Content  
         Content  
         Software Elemente
         Software Elemente
![Input Collection 1](https://pad.gwdg.de/uploads/c05296f20b96fd93af8f5f537.png)

Aktuelle Version vom 24. März 2022, 14:41 Uhr

Das 7. RDMO Community-Treffen fand am 02.03.2022 virtuell statt. Nach drei kurzen Reports aus Steuerungs-Gruppe, Content-Gruppe und Software-Gruppe wurden 2x2 Breakout-Sessions gemacht unter dem Thema:

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

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

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

Zusammenfassung der Mitschriften

Content-Themen

  • Konkrete Bedarfe

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

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

  • Möglichkeiten Statistiken zur RDMO-Nutzung aus dem System zu ziehen. (Gibt es verwaiste Projekte?; Welche Fragenkataloge werden häufig genutzt?; usw.)
  • Versionierung von Katalogen: Momentan gibt es in Projekten fehlende Werte, wenn Fragen in neuen Versionen hinzukommen.
  • Einfaches Klonen von Datensätzen / Projekten in RDMO.

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

  • Bereits etablierte/s Dienste / Vorgehen

Wachsendes Portfolio an geteilten Plänen / Vorlagen.

- offener Entwicklungsprozess (Open development)

- große Auswahl an Optionensätze erleichtern RDMO-Nutzung

  • Community-Beteiligung

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.

- Wege am Entwicklungsprozess mitzuwirken besser darstellen:

-- Zugang zum Slack ist momentan nur auf Einladung möglich

-- GitHub kann DMP-Entwickler, die noch mit klassischen Textverarbeitungsprogrammen arbeiten, verunsichern. Wer sind Ansprechpartner, die Ideen und Anforderungen in Issues übersetzen können?

-- Nutzen der Wiki-Funktion auf GitHub, um Ideen und Vorschläge abseits der Issues zu kommunizieren

-- Unterstützung bei der Content-Erstellung / Nutzung (Expertenhilfe / RDMO-Sprechstunde)

  • Lessons learnt

- Content muss laufend gepflegt werden

- Begleitete DMP-Erstellung mit RDMO ist für Forschende einfacher

Technik / Software

  • Diskussionsgrundlage aus der RDMO-Software-AG

Es geht in dieser Runde aus Sicht der AG weniger um die Details, dafür ist die Zeit zu knapp, sondern mehr um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.

- Anforderungen an den Content sind meist drängender als an die Technik / Software

- Frage an die Teilnehmenden aus der AG: Gibt es Ideen für einen breiteren Prozess, wie man die Finanzierung von Vorschlägen organisiert? Das "wer" ist dann der nächste Schritt.


  • Zusammenfassung des Brainstormings

- Wie organisiert man nach der Entscheidung für eine Maßnahme / Entwicklung die Umsetzung?

-- Bei Entwicklungen, die von einzelnen Einrichtungen gewünscht werden, werden die Resourcen von den Einrichtungen bereitgestellt. Damit sind momentan auch viele Entscheidungen, was gemacht wird, an einzelne Einrichtungen gebunden.

-- Ziel der Community sollte es auch sein, Einrichtungen, die ähnliche interessen / Anforderungen haben zusammenzubringen. Als ersten Schritt wäre eine Übersicht, an was gerade gearbeitet wird oder über welche neuen Funktionen nachgedacht wird hilfreich.

-- Ein rein Einrichtungs-zentrischer Ansatz tendiert dazu, wichtige, aber weniger attraktive Aufgaben, wie Security-Fixes, zu vernachlässigen.

-- Der Entwicklungsprozess/die Roadmap muss verfügbarer Ressourcen und die Bedarfe matchen.

-- Lässt sich hierfür ein Voting-System einführen (Community-Feedback, Priorisierung)? RDMO ist momentan noch recht zentralistisch.


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

- Ausbau des Entwicklerpools -- Crash-Kurs für Einsteiger in die Entwicklung

-- Mehr Informationen zur Plugin-Entwicklung

- Festlegen von Entwicklungsguidelines und -Plänen

-- Grundprinzipien, die bei der RDMO-(Mit-)Entwicklung berücksichtigt werden sollten

-- Workflow für GitHub-Requests

-- erhöht Tranparenz der Prozesse

  • Erste Entwicklungswünsche

- Verbessertes User-Interface

-- moderneres Interface erhöht Akzeptanz bei Forschenden (Frontend)

-- graphische IDE für Content-Entwicklung

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

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

- Schnittstellen zu anderen Systemen als Chance für breitere Nutzung / höherer Interoperability

-- Verknüpfen von Forschungsinformationssystemen (CRIS / FIS) mit RDMO

-- Datenübernahmen ersparten Doppelarbeit

-- bestehende Anbindung zu RADAR und Zenodo sind gute Beispiel dafür

-- RDMO (dann) auch als Projektmanagement-Software (jenseits von DMP)

  • Abschluss

Wie erfahren muss man sein, um an der Entwicklung mitarbeiten zu können?

- Es ist weniger FDM-Wissen nötig, sondern mehr Umgang mit und Programmierungsarbeit für Webanwendungen

- Abschlussarbeiten haben einen Betreuungsaufwand. Studentische Hilfkräfte sind ähnlich.

- Idee der Roadmap ist auch folgendes: Eine Einrichtung braucht etwas, hätte auch Geld, aber keine Programmierkenntnisse. Eine andere Einrichtung hätte IT-Praktiker (z.B. SHK) an der Hand.


Notizen zum RDMO-Treffen Breakout-Raum 2

Technik / Software
  • Drei Punkte vorneweg für die Diskussion:
    • Es geht nicht so stark um die Details, sondern eher um den Prozess, wie man Entscheidungen fällt und es dann umsetzt.
    • Content ist meist drängender als Technik
    • Gibt es einen breiteren Prozess, wie man die Finanzierung von Ideen organisiert?
    • Das "wer" ist dann der nächste Schritt.
  • Fragen / Punkte :
    • entscheiden nicht die Institution, die Ressourcen in die Programmierung steckt, was gemacht wird?
    • Das Problem hierbei ist das wichtige, aber wenig attraktive Aufgaben dann ggf. nicht gemacht werden (Security fixes, ...)
    • Man muss die Einrichtungen zusammenbringen, die ähnliche Interessen haben. Dazu wäre eine Übersicht, wer gerade an was arbeitet oder über eine bestimmte Entwicklung nachdenkt, hilfreich.
    • Kann man hier ein Voting-System einführen? (Priorisierung, Community-Feedback)
  • Modularität von RDMO
    • die Plugins sind ein wichtiger Schritt in diese Richtung
  • Gibt es schon FIS/CRIS, die mit RDMO verbunden sind
    • Das ist prinzipiell über Plugins möglich, aber bis alle FIS ein Austauschformat / eine Austausch-Schnittstelle haben, wird es für viele FIS eigene Plugins brauchen.
  • Gibt es Entwicklungs-Guidelines?
    • Wie soll Code aussehen, der in RDMO eingebracht werden soll? Hierzu wäre ein Good-Practice-Dokument hilfreich.
  • Neue UI, um eine moderne Oberfläche zu haben. Das ist wichtig um Wissenschaftler anzusprechen.
    • Wie ist der Workflow für Requests in GitHub?
  • Was sind Roadmaps in anderen Open Source Projekten?
    • Man muss die Anforderungen der Nutzenden abgleichen. Viele sind noch nicht so lange dabei, daher ist RDMO momentan noch sehr zentralistisch.
Content-Teil
  • Soll die Roadmap nicht nur Software, sondern auch Content-Gruppen-Material (Anleitungen, Tenmplates, DMP-Vorlagen, ...) abdecken?
    • Das ist sinnvoll und besonders wichtig für die Transparenz.
  • Zu Templates von Projekten die schon vorausgefüllt sind: Es gibt schon die (programmatische) Eltern-Kind-Funktion in Projekten. Hier konnen bereits Informationen übernommen werden. Wäre das eine lösung?
  • Projektinformationen aus den Katalogen herausnehmen und in die Projekterstellung verschieben
    • Basale Informationen (Förderer,...) sollten als "Projektmetadaten" hinterlegt werden, die Fragenkataloge können dann die Daten beschreiben.
  • Wie kann man sich besser / einfacher an der Content-Gruppe beteiligen?
  • Stellt Github hier eine Barriere da?
  • Wie können Personen, die noch klassisch in Textverarbeitungsprogrammen die Ideen niederschreiben, sich einbringen?
    • Ansprechpartner die Ideen und Anforderungen in Issues übersetzen.
    • Die GitHub-Wiki-Funktion könnte auf dem RDMO-GitHub für eine Kommunikation und zum Ablegen von textuell festgehaltenen Ideen (abseits von Issues) genutzt werden.
    • Zugang zum Slack ist momentan noch auf Einladung: Mail an Jochen Klar oder Olaf Michaelis.
    • Grundsätzlich verschiedenen Wege zur Kommunikation anbieten
  • Ist die Einstiegshürde in RDMO noch zu hoch? Brauchen wir mehr Materialien für den Einstieg?
  • Notsituation "DMP wird schnell benötigt" nutzen für Konversion in dem Sinne, dass aus einem RDMO-Projekt eine Projektbegleitung wird.



Notizen zu RDMO Breakout-Raum 1

Content-Teil

- open development ok:

       Templates für Datenstrukturen 
       Clonen von Datensätzen 

- einfaches Ausfüllen : 2-3 Detaillierungsgrade

       verschiedene Level

- RDMO => generierung von DMP

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

- “Expertenhilfe” organisieren ?

 ‘zuweisen’ von Fragen an Experten ? 

- 20-30 Kataloge bei Mandanten-Version (übersicht)

- Statistiken … horizon / DFG template

- Sammlung der Kataloge ( )

Technik/Software

=> Planung der Entwicklung:

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


=> Entwicklungsprozess muss Mittel und Bedarfe matchen

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

=> mehrere Entwickler benötigt:

       Crash-Course RDMO development? 
       Einführungskurs (JK) evtl. wiederholen 

=> Plugin Entwicklung


=> Hereinnahme von anderen Funktionen als DMP Produktion

       Schnittstellen zu anderen Systemen
       Software management

Projektmanagement ?


=> Beteiligung durch SHK oder andere Ressourcen …..

       Betreuung durch RDMO 
       Content 
       Software Elemente