AFANDI Docs / Plugin Management
← Back to overview Getting Started

Plugin Management

selection, assessment and Updateprozess for Moodle-Plugins incl. Test and rollback.

Moodle AFANDI standard Handover-ready documentation reviewed on a regular cycle

Quick overview

This page describes the working standard for Plugin Management – with a focus on concrete decisions rather than general guidance.

The main focus here is approval neuer plugins and upgrade-blocker through plugins so that teams apply the same standard.

The standard only becomes traceable through linked evidence such as plugin-liste / matrix and through documented edge cases/exceptions.

Practical focusTopic-specificVerifiable

When this page helps

Typical situations in which this page adds value as a working document, and where another document is more appropriate.

Typical use cases

  • when for Plugin Management technical standards about eingesetzte plugins incl. version and zweck must be documented in a binding way
  • when team handovers or temporary cover the same process for approval neuer plugins should be able to execute safely
  • when incidents or Changes show that evidence such as plugin-liste / matrix are still missing
  • when configuration or operational deviations (e.g. plugin becomes produktiv activeiert without staging-test) occur repeatedly

Less suitable when

  • when Plugin Management only about a one-off individual case without need for standardization applies
  • when a detailed project ticket or a technical step-by-step guide is the better fit

Recommended process

A pragmatic sequence that works in practice, from scope to review.

  1. capture the current state and scope for Plugin Management capture, including eingesetzte plugins incl. version and zweck and critical dependencies.
  2. define the target state and standards; key decisions include approval neuer plugins.
  3. test changes in a controlled way (Staging, Testsystem or Checklist) and Ergebnis document.
  4. implement in production, run follow-up checks, and plugin-liste / matrix + staging-testergebnisse link.
  5. Monitoring/Reviews auswerten and recurring Befunde such as „Plugin becomes produktiv activeiert without Staging-Test“ in the standard einarbeiten.

Decision rules

Note: The general documentation rules remain central. On this Page dokumentierst du only decisions, the Plugin Management clearly steuern. Central guideline.

Plugin Management is well documented, when rules, Edge cases and Evidence so clearly are, dass teams so that without additional coordination work can.

scope & Wirkung

For Plugin Management first define the scope clearly: eingesetzte Plugins incl. Version and Zweck.

approvalregel

decisions about approval neuer plugins and upgrade-blocker through plugins not implizit lassen, sondern roles and approvals explicitly benennen.

Exceptions cleanly halten

Allow exceptions only if they do not dilute the standard; especially relevant here are compatibility to the moodle-version.

Verifiablekeit

Verifiable is the rule only, when plugin-liste / matrix and staging-testergebnisse cleanly verlinkt are.

What should be documented

Here only the spezifischen Inhalte about Plugin Management maintain; general documentation rules remain in the centraln guideline. Central guideline.

The page is good when a substitute can apply or review the standard without first collecting tribal knowledge.

scope

terms, scope and boundaries about Plugin Management specify in concrete terms, including eingesetzte plugins incl. version and zweck.

Concrete Parameter/rules

Den standard so record, dass approval neuer plugins and deactiveierung/abkündigung eindeutig entschieden are.

evidence

Name and link evidence directly: Plugin-list / Matrix, Staging-Testergebnisse, approvalprotokoll.

Versionierung

Aktive Exceptions, the latest change and the next review belong on the page—especially for topics with compatibility to the moodle-version.

Common pitfalls

This section captures real-world pitfalls from Plugin Management; general guidance belongs in the central guideline. Central guideline.

  • scope driftet: Plugin becomes produktiv activeiert without Staging-Test.
  • the rule is too abstract: compatibility to the target version is unclear.
  • evidence is missing: Owner for a Plugin is missing.
  • the exception gets out of control: staging and production drift apart.
Tip: It is better to document three concrete observations from real cases than to keep a long generic list.

Moodle reference (official docs 5.1)

Kurze Verweise on the offizielle Moodle documentation for Plugin Management. So remains this Page AFANDI-spezifisch and vermeidet doppelte Grundlagen.

Official references

Documentation focus

  • Plugin-Lebenszyklus document: selection, Test, approval, Updatepfad and Owner.
  • UI path, role and test case record explicitly (not only the desired target state).
  • Mark deviations from AFANDI standards separatelyely so that updates remain easier to review.
Note: Moodle interfaces, paths, and options can vary depending on the version, theme, and enabled plugins. Therefore always include the version, role, and test context on the page.

Review & maintenance

Check this Page gegen reale processes about Plugin Management – not only gegen the Wortlaut. Entscheidend is, ob standard, Exceptions and Evidence in the Alltag contribute.

  • Ist the Plugin-list fully?
  • Passen Plugins to the Moodle-Version?
  • Gibt it ungenutzte or veraltete Plugins?
  • Stimmen Konfiguration and documentation match?

Review focus for „Plugin Management“: Plugins; check especially eingesetzte plugins incl. version and zweck.

Useful metrics

A few metrics are enough – what matters is that they trigger decisions or improvements.

For „Plugin Management“ Kennzahlen directly an approval neuer plugins and the most frequent Praxisrisiken koppeln.

Plugin-Aktualität

Anteil Plugins on freigegebenem Stand

Interval: monthly

Kompatibilitäts-Blocker

Anzahl Plugins, the Upgrades blockieren

Interval: monthly

Staging-Testquote

Anteil Plugin-changes with Staging-evidence

Interval: monthly

Next steps

Add jetzt the concrete Entscheidung about approval neuer plugins incl. Verantwortlichen, Datum and Verweis on plugin-liste / matrix.

On „Plugin Management“ make especially clear as the next step: which eingesetzte plugins incl. version and zweck apply in the standard case and which exceptions are time-limited.