Benutzer-Werkzeuge

Webseiten-Werkzeuge


docuteam:improvements

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
docuteam:improvements [2019/06/11 12:52] Andreas Nefdocuteam:improvements [2019/09/12 09:03] – [In Arbeit] Tobias Wildi
Zeile 4: Zeile 4:
 Wir erhalten regelmässig Inputs und Vorschläge für die Weiterentwicklung unserer Werkzeuge. Um die Roadmap allen Benutzern unserer Software zugänglich zu machen, publizieren wir nicht nur die Vorschläge, sondern zeigen auch an welchen Features wir gegenwärtig arbeiten. Wir setzen die Features nach und nach um, finanziert einerseits über Projekten ("Bounty-Modell"), andererseits über die Wartungsverträge, welche regelmässige Basisverbesserungen möglich machen und für alle die Nachhaltigkeit sichern. Wenn Vorschläge über die Wartungsverträge finanziert werden, dann nimmt in der Regel docuteam die Priorisierung vor. Wenn Features innerhalb eines vorgegebenen Zeitraums umgesetzt werden sollen, dann muss dafür ein Projekte formuliert werden und wir reservieren dann auch gerne die notwendigen Kapazitäten für die Entwicklung und das Testen. Wir erhalten regelmässig Inputs und Vorschläge für die Weiterentwicklung unserer Werkzeuge. Um die Roadmap allen Benutzern unserer Software zugänglich zu machen, publizieren wir nicht nur die Vorschläge, sondern zeigen auch an welchen Features wir gegenwärtig arbeiten. Wir setzen die Features nach und nach um, finanziert einerseits über Projekten ("Bounty-Modell"), andererseits über die Wartungsverträge, welche regelmässige Basisverbesserungen möglich machen und für alle die Nachhaltigkeit sichern. Wenn Vorschläge über die Wartungsverträge finanziert werden, dann nimmt in der Regel docuteam die Priorisierung vor. Wenn Features innerhalb eines vorgegebenen Zeitraums umgesetzt werden sollen, dann muss dafür ein Projekte formuliert werden und wir reservieren dann auch gerne die notwendigen Kapazitäten für die Entwicklung und das Testen.
  
-==== Vorschläge ====+==== Vorschläge/Planung ====
   * Kontrolliertes **Löschen von AIP** aus dem Repository. Eine Möglichkeit wäre, in einem Workflow die Root-PID des Objekts anzugeben und dann das gesamte Objekt zu löschen. Die Herausforderung dieser Funktionalität sehen wir vor allem auch in der sorgfältigen Konzipierung, um Bedienungsfehler und unbeabsichtigtes Löschen zu verhindern.   * Kontrolliertes **Löschen von AIP** aus dem Repository. Eine Möglichkeit wäre, in einem Workflow die Root-PID des Objekts anzugeben und dann das gesamte Objekt zu löschen. Die Herausforderung dieser Funktionalität sehen wir vor allem auch in der sorgfältigen Konzipierung, um Bedienungsfehler und unbeabsichtigtes Löschen zu verhindern.
     * Umsetzung sollte dann auch über docuteam bridge zugänglich sein.     * Umsetzung sollte dann auch über docuteam bridge zugänglich sein.
Zeile 10: Zeile 10:
     * Grob diskutiert am Community Day 2018     * Grob diskutiert am Community Day 2018
     * Wette in Gang Tobias/Marion zum Zeitplan Konzept     * Wette in Gang Tobias/Marion zum Zeitplan Konzept
 +  * docuteam bridge 
 +    * Updates und Deletions 
 +  * docuteam packer mit Submit-Funktion nach docuteam bridge 
 +  * Überarbeitung der Ablieferungsvereinbarungen 
 +    * Die aktuellen Ablieferungsvereinbarungen bieten – aufbauend auf ISO 20652:2006 (CCSDS 651.0-B-1:2004) – ein relativ umfassendes Vokabular an. 
 +    * In der Praxis zeigt sich jedoch, dass nur ein kleiner Teil davon effektiv genutzt wird. Eine künftige Version soll sich darauf konzentrieren, aber wichtige Features konsequenter und verständlicher umsetzen.
 ==== In Arbeit ==== ==== In Arbeit ====
 Unsere Softwareentwicklung konzentriert sich gegenwärtig auf die folgenden Punkte (Stand Juni 2019): Unsere Softwareentwicklung konzentriert sich gegenwärtig auf die folgenden Punkte (Stand Juni 2019):
Zeile 17: Zeile 22:
     * Version 4.1     * Version 4.1
     * dynamisches Mapping     * dynamisches Mapping
-  * Fedora 4 +  * Fedora 4 (resp. Version 6 im Frühjahr 2020) 
-    * Data- and Metadata-Model Matterhorn RDF, siehe Dokumentation: [[docuteam:matterhornrdf|Matterhorn RDF Datamodel]] +    * Data- and Metadata-Model Matterhorn RDF, siehe Dokumentation: [[docuteam:matterhornrdf|Matterhorn RDF Datamodel]]. Zu diesem Zweck engagieren wir uns auch in der [[https://vsa-aas.ch/arbeitsgruppen/projektgruppe-ensemen/|Projektgruppe Ensemen des VSA,]] wo ein Metadatenmodell basierend auf bestehenden Ontologien entwickelt wird. 
-    * Storage-Adapter für docuteam feeder, um Objekte in Fedora zu speichern+    * Storage-Adapter für docuteam feeder, um Objekte in Fedora zu speichern
     * Anpassung von docuteam rservices für die Auslieferung von Nutzungskopien und DIP aus Fedora 4     * Anpassung von docuteam rservices für die Auslieferung von Nutzungskopien und DIP aus Fedora 4
-    * Update- und Migrationsmethoden Fedora 3.8 auf Fedora 4.x +    * Update- und Migrationsmethoden Fedora 3.8 auf Fedora 6 
-  * docuteam bridge +  * Java 11-Kompatibilität 
-    * Updates und Deletions+    * Mit dem Wechsel von Oracles Release-Zyklus für Java unterstützen wir künftig jeweils die Long Term Support (LTS)-Versionen. 
 +    * Im Frühjahr 2020 (mit Verfügbarkeit von Fedora 6) stellen wir auf Java 11 um.
  
 ==== Erledigt ==== ==== Erledigt ====

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki