Protokoll

Renate: Anmoderation und Vorstellung des Gastes Joao Martins von der Universitäts- und Stadtbibliothek Köln.

TOP 1 Bericht zu PKP Sprint (Renate Voget)

• Entwicklercommunity PKP (Public Knowledge Project) entwickeln OJS, OMP und OPS
• verortet an Simon Fraser University in Kanada
• veranstalten i.d.R. 2x jährlich Sprints, verteilt auf jeweils 1x USA und 1x Europa
• Zielführung der Sprints, Zitat von der Website "Sprints are free, fun, and interactive events for our community to brainstorm important tasks, set priorities, and work together to improve our open source software."
• PKP verstehen ihre Community als Redaktionen, Bibliotheken, Universitäten, Entwickler*innen
• Sprint war wenig Tech-lastig, es stand eher die Usability der Software im Vordergrund
• der diesjährige Sprint fand in Turin statt, im Circolo dei Lettori
  • 8.-9. Oktober
  • danach noch zwei Tage Craft OA Tech Event > soll hier nicht im Fokus stehen
• Teilnehmer*innen: ca. 20 externe, ca. 10 von PKP
• Offene Gestaltung - Gruppenbildung und Pitches
  • Themen wurden in Pitches vorgestellt, davon ausgehend wurden Arbeitsgruppen gebildet, die teilweise über die 2 Tage gearbeitet haben
• Präsentation von Fotos vom Ablauf

TOP 2 Bericht zu zwei Gruppenarbeiten beim PKP Sprint (Plugin-Gruppe, Joao Martins (USB Köln))

• Ankündigung OJS Version 3.5 Release kommt vsl. Ende 2024; die LTS (=Long Term Support) Variante davon erst Q2/25
• PKP hat eine EU Förderung für die Plattform ORE, wird dafür Verbesserung der Software entwickeln, diese erscheinen vsl. in Version 3.6 in Q2/2026
•  z.B.
  • Preprint-Workflow
  • offene Peer-Review mit Editor
  • Ausgangsformate wie JATS
• Gruppenarbeit, an der Joao teilgenommen hat
• 1. Gruppe: Typesetting, HTML, XML
  • • Pitch: OJS für kollaboratives Schreiben nutzen
    • mehr als 20 Mitglieder in der Gruppe, sehr groß, Gruppe daher in 4 Untergruppen geteilt
    • Pitch war zugleich Anforderung der EU (vgl. dazugehörige Publikation: https://op.europa.eu/en/publication-detail/-/publication/cc087fd8-82b3-11ee-99ba-01aa75ed71a1/language-en )
    • es gibt bereits ein Editor-Tool, das evtl. dafür in OJS integriert werden könnte (schwedischer Entwickler, sitzt in Bonn, Deutschland)
    • Außerdem Überlegung, KI zur Metadata-Extraction zu nutzen, z.B. per GROBID
    • haben in der Gruppe auch über andere Tools gesprochen
• 2. Plugin-Gruppe
  
  • Pitch: Plugins führen oftmals zu Absturz oder sind nicht genormt hinsichtlich php-Version. Wie können wir Prozesse verbessern, damit wir einen Überblick bekommen, was funktioniert und was nicht? Notlösungen?
  • Joao hat den Pitch gehalten, Alex Smetcher (PKP Chefentwickler) und andere haben teilgenommen
    
    • Lösungsvorschläge:
      • Werkzeug zum Deaktivieren von fehlerhaften Plugins
      • OJS weiß nicht, ob ein Plugin ein Problem verursacht, sondern man muss es erst installieren. wenn man wüsste für welche Version das Plugin kompatibel ist, dann wäre besser (Server-Informationen angelegt dazu)
      • Hook: in PKP-Core kann man laufen lassen und Möglichkeit, dass wenn Plugin Fehler verursacht, OJS das Plugin selbstständig deinstalliert
      • haben Plugin entwickelt: "The worst Plugin ever-Plugin", um diese Lösungen zu testen
        • absichtliche Fehler codieren in einem Plugin, damit es failed, war eine innovative Herangehensweise
        • hier auch: Plugin deaktivieren als eigenes Tool
• Gruppen, an denen er nicht teilgenommen hat
  
  • gab auch andere Workgroups, wo viel über OMP gesprochen wird
  • DSGVO 
  • weitere

TOP 3 Offener Austausch

• Teilnehmer*in: An unserer Institution haben wir seit längerer Zeit kein Upgrade gemacht bzw. neue Plugins hinzugefügt, da eben die Problematik der Instabilität von OJS besteht. Wir warten, dass unsere Instanzen auf hbz-Server kommen. Finde "The worst Plugin ever" einen guten Ansatz; Plugins sauber entfernen zu können, ist sehr hilfreich.
• Joao: es ist auch problematisch auf Upgrades zu verzichten, da Sicherheitsupdates notwendig sind. Beispiel für ein Plugin, das nicht php 8.0 kompatibel: hat mehrere Zeitschriften zum Absturz gebracht. Konnten sie zum Glück in Plugin selbst lösen, Code haben sie dann auf GitHub beim entsprechenden Entwickler geteilt. Dieser hat dann neue Version für Plugin released für OJS 3.4. Es ist immer gut, mit Herstellern zu kommunizieren (hier auch 3rd Party Plugin). Ziel ist es für ihn, dass einzelne Plugins nicht die allgemeine Entwicklung der Software kompromittieren.
• Renate: Wie kann man User adressieren, mit ihnen zu diesen Änderungen kommunizieren? 
• Teilnehmer*in: an ihrer Institution findet ein Abgleich statt, was in der alten Version vorhanden war und was nach einem Upgrade auf der neuen anders sein wird. Dafür wird ein Abzug der Daten von dem Produktivsystem auf das Testsystem gemacht. Dann wird das Testsystem geupgraded. Dann wird eine Liste mit Änderungen erstellt. Diese umfasste z. B. bei OJS 3.3 zu 3.4 sieben Seiten an Änderungen (z.B. Layout, das sich verselbstständigt, Zitationen, die nicht mehr übernommen wurden, welche Felder in Erfassungsmaske nicht mehr vorhanden sind oder andere)  
• Vorschlag, das positiv zu kommunizieren: "das Upgrade hat das und das neu mitgebracht".
• Joao macht Übersicht was geupgraded wird und listet das
  • Manches wurde nachjustiert, z.B. eine Zeitschrift, bei der die Redaktion in der Spracherklärung die Regionalität nachgewiesen haben wollte. Sowas übernimmt OJS nicht. Da wurde Hand angelegt (hartkodiert). Das wird man dann vielleicht bei jedem Upgrade haben, dass dann lokale Änderungen bei Upgrades nachgezogen werden müssen. 
• Teilnehmer*in: Hartkodierte Änderungen sind einfach schwierig. Nach Upgrade funktioniert das nicht mehr. Redaktionen zeigen leider oft wenig Verständnis, aber es gibt sicherheitstechnisch wenig Diskussionsspielraum. Haben sich dann entschlossen, alle Instanzen an der Bib einzufrieren. Hofft, dass sie Zeitschriften mit dem hbz hosten können, um sie diesbezüglich zu entlasten. Was hilfreich wäre, wäre ein Art Baukasten- oder Modulsystem - z.B. "wir haben die und die Plugins, daraus könnt ihr eine Auswahl treffen". Vorschlag: eher Vorteile in den Vordergrund rücken in Kommunikation und nicht die Probleme. 
• Teilnehmer*in: wir haben den Zeitschriften ziemlich viel Freiheit gelassen, aber das ist jetzt bei Upgrades schwierig. Jede Zeitschrift konnte und kann individuell gestaltet werden. Insbesondere hoher Bedarf hier beim Layout. Am unproblematischsten ist aber einfach das OJS-Standard-Theme. Bei Upgrades kann es eben ansonsten Schwierigkeiten geben. In der Beratung wird darauf hingewiesen.
• Teilnehmer*in: Haben 20 bis 21 Zeitschriften, die auf einer Instanz laufen. Haben "Start-Set Plugins", die wir für Zeitschriften bereitstellen plus optionale, die sie sich aussuchen können. Die sind gesetzt und das kommunizieren wir Redaktionen auch zu Beginn. Wenn sie Sonderwünsche haben, testen wir das zuerst. Beispiel, ein Herausgeber hat sich ein Plugin gewünscht, das auf Prod getestet wurde - das kleine Plugin hat die gesamte Instanz gecrasht. Da haben wir gesagt, so was machen wir auf keinen Fall mehr auf Prod. Die werden auf jeden Fall erst auf Testinstanz getestet. Bei Upgrade auf 3.3 haben wir außerdem viele Plugins abgestoßen. Alle Plugins werden grundsätzlich erst auf Test getestet, bevor sie auf Prod können. Bei Upgrades werden Redaktionen informiert und es wird gebeten, sie sollen testen, ob Zeitschriften noch funktionieren, nach dem Upgrade. Auch hinsichtlich Layout. Zusätzlich werden Redaktionen gebeten, Plugins nur unter vorheriger Rücksprache zu aktivieren. 
• Teilnehmer*in: wie ist denn die Akzeptanz bei euch?
• Teilnehmer*in: wir setzen die Zeitschriften gemeinsam mit den Redaktionen auf, das ist das Minimum, das sie an Zeit investieren. Akzeptanz ist schon gegeben, wenn man das gut verargumentiert. 
• Renate: Wie ist das an anderen Standorten, wo ausschließlich mit einem Standard-Setting gearbeitet wurde?
• Teilnehmer*in: Hatten mit Plugin-Thema keine größeren Probleme, weil von vornherein nicht so viele Plugins im Einsatz waren.
• Renate: hbz bietet out-of-the-box Plugins von PKP + max. 10 weitere Plugins an. Schauen dabei nach Kernfunktionalitäten.
• Teilnehmer*in: Wunsch nach einer Authentifizierung bei Anmeldung, wird von HS-Leitung gefordert.
  
  • Anna: Am hbz wir haben wir OpenID-Plugin probiert, ist gecrasht, deshalb warten wir auf 3.5(LTS)-Version, in der das hoffentlich gelöst ist. So ist das Plugin nicht einsetzbar. Gilt auch für andere Plugins, die wir durchgetestet haben. Insbesondere vor PHP-Problematik, wie von Joao erwähnt.
  • Joao: 2-Faktoren Authentifizierung plus Single-Sign-On soll Core Feature von 3.5 werden.
    
    • es gibt immer Plugins auch PKP-seitig, die nicht mehr weitergeführt werden. Wenn nicht weitergeführt wird bzw. kein core feature ist, können wir nichts versprechen. Müssen auch Redaktionen sagen, das und das hat sich verändert und damit muss man dann leben. Entweder wir machen beim Fortschritt der Software mit oder müssen aussteigen. Veränderungen im Core müssen akzeptiert werden, wenn wir da mitmachen wollen. Man kann z.B. auch mit Sonderschulungen etwas erreichen. PKP macht auch viele Webinare - da ist eben die Frage nach Vorteilen, die es zu adressieren gilt - das ist eine wichtige Sache zu sagen, dieses und jenes wird sich verbessern. Es kommen ja auch immer neue Plugins dazu. Die Leute sind super begeistert über die Entwicklung. Man hat auch ein Gefühl, dass neue Sachen entwickelt werden, die die Veröffentlichungslandschaft positiv beeinflussen.
• Abmoderation Renate: Wir haben gelernt, dass man Vorteile von technischem Fortschritt durch Upgrades betonen und gegenüber Redaktionen kommunizieren sollte, z.B. durch gezielte Schulungen. Vielen Dank für die Teilnahme!