Plugin-Kompatibilitätsmatrix
Kompatibilität von Plugins pro Moodle-Version und Release-Fenster steuern.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für Plugin-Kompatibilitätsmatrix – mit Fokus auf konkrete Entscheidungen statt allgemeiner Leitlinien.
Zentral sind hier vor allem freigabe neuer plugins und upgrade-blocker durch plugins, damit Teams denselben Maßstab anwenden.
Nachvollziehbar wird der Standard erst durch verlinkte Nachweise wie plugin-liste / matrix und durch dokumentierte Grenzfälle/Ausnahmen.
Wann diese Seite hilft
Typische Situationen, in denen diese Seite als Arbeitsdokument Mehrwert bringt – und wo eine andere Doku passender ist.
Typische Einsätze
- wenn bei Plugin-Kompatibilitätsmatrix technische Standards zu eingesetzte plugins inkl. version und zweck verbindlich dokumentiert werden müssen
- wenn Teamwechsel/Vertretung denselben Ablauf für freigabe neuer plugins sicher ausführen soll
- wenn Störungen oder Changes zeigen, dass Nachweise wie plugin-liste / matrix bisher fehlen
- wenn Konfig- oder Betriebsabweichungen (z. B. plugin wird produktiv aktiviert ohne staging-test) wiederholt auftreten
Eher nicht passend bei
- wenn es bei Plugin-Kompatibilitätsmatrix nur um einen einmaligen Einzelfall ohne Standardisierungsbedarf geht
- wenn ein detailliertes Projektticket oder eine technische Schritt-für-Schritt-Anleitung gepflegt werden soll
Empfohlener Ablauf
Pragmatische Reihenfolge, die in der Praxis funktioniert – vom Scope bis zum Review.
- Ist-Stand und Scope für Plugin-Kompatibilitätsmatrix erfassen, inklusive eingesetzte plugins inkl. version und zweck und kritischer Abhängigkeiten.
- Sollzustand / Standards festlegen; wichtig sind Entscheidungen zu freigabe neuer plugins.
- Änderungen kontrolliert testen (Staging, Testsystem oder Checkliste) und Ergebnis dokumentieren.
- Produktiv umsetzen, Nachtests durchführen und plugin-liste / matrix + staging-testergebnisse verlinken.
- Monitoring/Reviews auswerten und wiederkehrende Befunde wie „Plugin wird produktiv aktiviert ohne Staging-Test“ in den Standard einarbeiten.
Entscheidungsregeln
Plugin-Kompatibilitätsmatrix ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Scope & Wirkung
Für Plugin-Kompatibilitätsmatrix zuerst den Anwendungsbereich konkret machen: eingesetzte Plugins inkl. Version und Zweck.
Freigaberegel
Entscheidungen zu freigabe neuer plugins und upgrade-blocker durch plugins nicht implizit lassen, sondern Rollen und Freigaben explizit benennen.
Ausnahmen sauber halten
Ausnahmen nur zulassen, wenn sie den Standard nicht aufweichen; besonders relevant sind hier kompatibilität zur moodle-version.
Prüfbarkeit
Prüfbar ist die Regel erst, wenn plugin-liste / matrix und staging-testergebnisse sauber verlinkt sind.
Was dokumentiert werden soll
Hier nur die spezifischen Inhalte zu Plugin-Kompatibilitätsmatrix pflegen; allgemeine Doku-Regeln bleiben in der zentralen Leitlinie. Zentrale Leitlinie.
Die Seite ist dann gut, wenn eine Vertretung den Standard anwenden oder prüfen kann, ohne erst Personenwissen einsammeln zu müssen.
Anwendungsbereich
Begriffe, Scope und Grenzen zu Plugin-Kompatibilitätsmatrix konkretisieren – inklusive eingesetzte plugins inkl. version und zweck.
Konkrete Parameter/Regeln
Den Standard so notieren, dass freigabe neuer plugins und deaktivierung/abkündigung eindeutig entschieden sind.
Artefakte
Artefakte direkt nennen und verlinken: Plugin-Liste / Matrix, Staging-Testergebnisse, Freigabeprotokoll.
Versionierung
Aktive Ausnahmen, letzte Änderung und nächster Review gehören auf die Seite – besonders bei Themen mit kompatibilität zur moodle-version.
Typische Stolperfallen
Pflege hier echte Fallstricke aus der Praxis von Plugin-Kompatibilitätsmatrix; allgemeine Hinweise gehören in die zentrale Leitlinie. Zentrale Leitlinie.
- Umfang driftet: Plugin wird produktiv aktiviert ohne Staging-Test.
- Regel bleibt abstrakt: Kompatibilität zur Zielversion ist unklar.
- Nachweis fehlt: Owner für ein Plugin fehlt.
- Ausnahme entgleist: Release bündelt zu viele ungetestete Änderungen.
Moodle-Referenz (offizielle Doku 5.1)
Kurze Verweise auf die offizielle Moodle-Dokumentation für Plugin-Kompatibilitätsmatrix. So bleibt diese Seite AFANDI-spezifisch und vermeidet doppelte Grundlagen.
Offizielle Referenzen
Dokumentationsfokus
- Kompatibilitätsmatrix mit Moodle-Version, Plugin-Version und Teststatus pflegen.
- UI-Pfad, Rolle und Testfall explizit notieren (nicht nur den gewünschten Endzustand).
- Abweichungen von AFANDI-Standards separat markieren, damit Updates leichter reviewbar bleiben.
Prüfung & Pflege
Prüfe diese Seite gegen reale Vorgänge zu Plugin-Kompatibilitätsmatrix – nicht nur gegen den Wortlaut. Entscheidend ist, ob Standard, Ausnahmen und Nachweise im Alltag tragen.
- Ist die Plugin-Liste vollständig?
- Passen Plugins zur Moodle-Version?
- Gibt es ungenutzte oder veraltete Plugins?
- War der Scope realistisch?
Prüf-Fokus für „Plugin-Kompatibilitätsmatrix“: Plugins; prüfe dabei insbesondere eingesetzte plugins inkl. version und zweck.
Sinnvolle Kennzahlen
Wenige Kennzahlen genügen – wichtig ist, dass sie Entscheidungen oder Verbesserungen auslösen.
Für „Plugin-Kompatibilitätsmatrix“ Kennzahlen direkt an freigabe neuer plugins und die häufigsten Praxisrisiken koppeln.
Plugin-Aktualität
Anteil Plugins auf freigegebenem Stand
Intervall: monatlich
Kompatibilitäts-Blocker
Anzahl Plugins, die Upgrades blockieren
Intervall: monatlich
Staging-Testquote
Anteil Plugin-Änderungen mit Staging-Nachweis
Intervall: monatlich
Nächste Schritte
Ergänze jetzt die konkrete Entscheidung zu freigabe neuer plugins inkl. Verantwortlichen, Datum und Verweis auf plugin-liste / matrix.
Auf „Plugin-Kompatibilitätsmatrix“ als Nächstes besonders klar machen: welche eingesetzte plugins inkl. version und zweck im Standardfall gelten und welche Ausnahmen befristet sind.