Eine der häufigsten Anfragen, die ich bekomme, ist, eine vorhandene H5P-Inhaltstyp anzupassen, weil er bestimmte Funktionen nicht bietet oder nicht ganz den spezifischen Anforderungen entspricht. Obwohl es möglich ist, benutzerdefinierte Skripte hinzuzufügen, um zu erreichen, was du benötigst, ist es manchmal einfacher, den Code des Inhaltstyps direkt zu ändern.
Der erste Schritt ist, den „Maintainer“ des betreffenden H5P-Inhaltstyps zu kontaktieren. Auch wenn jemand anders möglicherweise die erforderlichen Änderungen vornehmen könnte, können sie diese dem „Maintainer“ nur anbieten. Letztendlich liegt es am Maintainer zu entscheiden, ob Fehlerkorrekturen oder neue Funktionen in den Originalcode aufgenommen werden sollen. Daher gibt es keine Garantie dafür, dass Änderungen, die du vornimmst und selbst verwendest, in das Hauptprojekt integriert werden.
Deshalb ist es wichtig, zuerst den ursprünglichen „Maintainer“ zu kontaktieren und deine vorgeschlagenen Änderungen zu besprechen. Sie werden dir mitteilen, ob sie daran interessiert sind, deine Funktion hinzuzufügen, und alle Anforderungen, die du erfüllen solltest. Sobald du grünes Licht bekommen hast, kannst du mit den Änderungen fortfahren und einen Pull-Request einreichen – eine Anfrage, deinen neuen Code in den Original-Code zu integrieren. Der Maintainer wird dann deinen Code überprüfen, möglicherweise einige Anpassungen verlangen und ihn dann zusammenführen, wenn alles in Ordnung aussieht, bevor er ihn veröffentlicht.
Wenn der Maintainer deine vorgeschlagenen Änderungen nicht genehmigt, hast du zwei Hauptoptionen, von denen jede ihre eigenen Vor- und Nachteile hat. Du kannst den H5P-Inhaltstyp „forken“, indem du im Wesentlichen deine eigene separate Version erstellst. Alternativ kannst du deinen Code patchen, während du die Möglichkeit für einen Pull-Request offen hältst.
Forking
Forking bedeutet, den aktuellen Code eines Inhaltstyps zu nehmen und eine Kopie (Klon) zu erstellen, die deinen Bedürfnissen angepasst werden kann, indem sie intern umbenannt wird. Diese Methode ermöglicht es dir, alles zu ändern, ohne Rücksicht auf jemand anderen nehmen zu müssen. Deine Änderungen haben keine Auswirkungen auf bestehende Inhalte, da für H5P dein Fork/Klon wie ein anderer Inhaltstyp ist. Du kannst ihn weiterentwickeln, wie es dir gefällt.
Ein Nachteil ist allerdings, dass du nicht automatisch von Fehlerbehebungen oder Erweiterungen des ursprünglichen Inhaltstyps profitierst, von dem du den Klon erstellt hast. In einigen Fällen können diese zwischenzeitlich getätigten Änderungen manuell hinzugefügt werden, aber je mehr sich die ursprüngliche Fassung und der Klon voneinander entfernen, desto schwieriger wird es. Das heißt letztlich: Du musst deinen Fork selbst pflegen. Wenn er von anderen Inhaltstypen abhängt, zum Beispiel Unterinhaltstypen verwendet, musst du die Abhängigkeiten selbst auf spätere Versionen aktualisieren. Bedenke auch: Sobald du mit dem Forken eines Inhaltstyps beginnst, könntest du schnell damit anfangen (müssen), auch andere Inhaltstypen zu forken.
Beispiel: Nehmen wir an, du hast Mark the Words geforkt. Du kannst Mark the Words in Column verwenden. Aber nur weil dein Fork auf dem Original von Mark the Words basiert, erscheint er nicht automatisch als Option in Column – wie bereits erwähnt, ist es für H5P wie ein völlig anderer Inhaltstyp. Daher musst du Column ebenfalls forken. Und dann möchtest du es vielleicht auch in Course Presentation haben, also musst du Course Presentation forken. Und so weiter und so fort… Das kann schnell außer Kontrolle geraten, und du könntest mit vielen Forks enden.
Ein weiterer Nachteil, der nicht offensichtlich sein dürfte: Ein Klon ist möglicherweise nicht wesentlich anders als das Original selbst. Das könnte ein Problem werden, wenn du das Original auch verwendest. Zum Beispiel könnten deine Benutzer *innen in der Lage sein, zwischen den regulären Image Hotspots und deiner alternativen Version mit einer zusätzlichen Funktion zu wählen. Welches sollten sie verwenden? Deine Version, weil sie eine zusätzliche Funktion hat? Die Originalversion, weil sie möglicherweise mittlerweile verbessert wurde? Die Dinge werden noch komplizierter, wenn es viele Variationen eines Inhaltstyps von verschiedenen Organisationen gibt und wenn Menschen Inhalte teilen – Benutzer*innen müssen sich möglicherweise nicht nur mit einer Alternative zu Image Hotspots auseinandersetzen, sondern mit mehreren. Und sie sind sich möglicherweise nicht einmal darüber im Klaren, dass sie mit dem Hochladen deines Klons diesen auf ihrer Plattform installieren würden. Das ist für dich möglicherweise nicht relevant, da du vielleicht eine geschlossene Plattform nutzt und deine Inhalte diese niemals verlassen, aber ansonsten solltest du darüber nachdenken.
Eine kleine Sache, die du zumindest im Hinterkopf behalten solltest: Wenn du bestehende Inhalte hast, die auf deinen Fork migriert werden sollen, wird eine einmalige Anpassung der Datenbank erforderlich. Das Prozedere wird je nach der Plattform, auf der du H5P nutzt, etwas variieren. Das Umkehren dieses Prozesses, falls du deine Meinung später änderst, ist jedoch möglicherweise nicht so einfach, da du wahrscheinlich deine neuen Funktionen verlieren würdest.
Patch / Pull Request
Die Option eines Pull-Requests beginnt auf die gleiche Weise wie das Forking: Du erstellst einen Klon eines vorhandenen Inhaltstyps. Der Unterschied ist, dass du den Klon intern nicht umbenennst. Für H5P ist das dann kein neuer Inhaltstyp. Du änderst technisch gesehen den vorhandenen, aber nur auf deiner lokalen Plattform. Du kannst alle Änderungen vornehmen, die du möchtest, genau wie oben beschrieben. Du solltest aber sehr vorsichtig sein, da Updates für den ursprünglichen Inhaltstyp deine Änderungen überschreiben würden – und Updates für Inhaltstypen können zusammen mit Updates für andere Inhaltstypen installiert werden, sodass du möglicherweise nicht einmal bemerkst, dass du deine Änderungen überschreibst. Schauen wir uns das an einem Beispiel an. Sagen wir, du hättest Multiple Choice geändert und es vermieden, den Inhaltstyp über den H5P-Hub zu aktualisieren. Das könnte trotzdem versehentlich passieren, indem du Course Presentation oder Interactive Video oder einen anderen Inhaltstyp aktualisierst, der Multiple Choice verwenden kann. Du müsstest deine Änderungen dann immer wieder einpflegen und ggf. anpassen. Natürlich ist das nicht erwünscht. Der Ausweg aus dieser Situation ist es, deine Änderungen den Betreiber*innen des ursprünglichen Inhaltstyps anzubieten (was wahrscheinlich H5P Group sein dürfte, das Unternehmen, das das H5P-Kernteam stellt). Wenn sie entscheiden, dass deine Änderungen eine gute Ergänzung sind, können sie deine Änderungen in ihren Quelltext hineinziehen – deshalb heißt dein Angebot auch „Pull-Request“.
Der Vorteil dieses Ansatzes ist, dass du leicht von Fehlerbehebungen oder neuen Funktionen profitieren kannst, die andere zum Inhaltstyp hinzugefügt haben. Du musst einfach den Inhaltstyp aktualisieren.
Außerdem gilt: Wenn die Betreiber*innen eines Inhaltstyps deine Änderungen akzeptieren, übernehmen sie irgendwie die Verantwortung für Probleme damit. Sagen wir, später entdeckt jemand einen Fehler in deinen Änderungen. In diesem Fall wäre es anständig, wenn du ihn behebst, aber strikt genommen ist es dann das Problem der Betreiber*innen.
Nun aber zu einem Nachteil: Die oben erwähnte Übertragung der Verantwortung könnte erklären, warum das Betreiber*innen von H5P-Inhaltstypen möglicherweise zögerlich reagieren, wenn sie Pull-Requests erhalten. Andere Gründe für Zögern könnten sein, dass deine Änderung einen speziellen Fall abdeckt, der für dich von entscheidender Bedeutung sein könnte – aber für andere Menschen überhaupt nicht relevant ist – gleicheitig aber die Gesamtkomplexität erhöht. Deshalb solltest du sicherstellen, dass die Betreiber*innen deine Änderungen vorab gutheißen. Selbst dann könnten sie nachträglich Änderungen wünschen, deine Anfrage nicht rechtzeitig bearbeiten, usw. Dann könntest du mit deinem lokalen Klon dasitzen und den Inhaltstyp (ohne erneutes Patchen) für eine ganze Weile nicht aktualisieren können – und in manchen Fällen sogar leichte Schwierigkeiten haben, wenn die Betreuer*innen Änderungen wünscht, die du nicht erwartet hast.
Daher solltest du, wenn du den Weg „Patch / Pull-Request“ vorziehst, sicherstellen, dass die Betreiber*innen mit deinen Änderungen einverstanden sind – insbesondere, wenn die Änderungen Auswirkungen auf die Benutzererfahrung haben. Und eventuell solltest du auch besprechen, wie die Änderungen konkret umgesetzt werden sollten.