Übungsaufgaben zu Wiki und Content-Management-System

Je Vorteil 1 Punkt, vier aus z. B.:

• Offenes System: Alle Beteiligten (Lehrkräfte, Schüler*innen, Schul-IT) können ihr Wissen selbst eintragen, nicht nur Dimitrios Papadopoulos.

• Ergänzungen und Berichtigungen jederzeit möglich: Fehler oder veraltete Angaben (z. B. eine geänderte Raumbelegung) werden sofort korrigiert.

• Historie nachvollziehbar: Die Versionsgeschichte zeigt, wer wann was geändert hat; fehlerhafte Änderungen lassen sich zurücksetzen.

• Bereichsübergreifende Nutzung: Orga-Team, Technikteam, Catering und Schulleitung sehen denselben Stand.

• Wissen bleibt erhalten, wenn Emre Aksoy und Mia Schröder die Schule verlassen; das Team für 2028 kann darauf aufbauen.

• Zentral und durchsuchbar: Volltextsuche statt Suche in E-Mails und 60 Dateien.

• Ortsunabhängig im Browser, auch am Smartphone am Veranstaltungstag.

• Kostengünstig: Die Software ist Open Source und wird von der Schul-IT bereitgestellt; keine Lizenzkosten.

Bewertungshinweis: Zwei Vorteile mit gleichem Kern (z. B. „aktuell“ und „Fehler können korrigiert werden“) zählen nur einmal.

• Explizites Wissen (1 Punkt) lässt sich in Worte, Tabellen oder Anleitungen fassen und dokumentieren. Beispiel (0,5 Punkte): die VLAN-Liste mit IP-Bereichen, die Packliste für den Technikaufbau am Freitag, die Anleitung zum Akkutausch der E-Ink-Türschilder, die Fristenliste.

• Implizites Wissen (1 Punkt) beruht auf Erfahrung und Können und lässt sich nur schwer oder gar nicht vollständig aufschreiben. Beispiel (0,5 Punkte): Emres Gespür, welcher Badge-Drucker gleich klemmt; wie man aufgeregte Referierende vor der Session beruhigt; welche Kabelwege sich im Gebäude bewährt haben.

• Weitergabe (1 Punkt): durch Zusammenarbeit, z. B. Emre arbeitet sein Nachfolgeteam beim Technikaufbau 2027 im Tandem ein, Hospitation, Erfahrungsrunde nach dem Barcamp (Lessons Learned). Teile davon lassen sich im Wiki sichtbar machen, etwa als Abschnitt „Typische Probleme und was hilft“ oder mit Fotos und kurzen Videos, und das Wiki nennt Ansprechpersonen.

• Wiki (2 Punkte): eine Sammlung verlinkter Webseiten, die die Nutzenden im Browser selbst anlegen und ändern können. Viele schreiben gemeinsam an einem Nachschlagewerk, das immer den aktuellen Stand zeigt; jede Änderung wird als Version gespeichert.

• Abgrenzung Blog (1 Punkt): Ein Blog ist eine chronologische Folge von Beiträgen einzelner Autor*innen; Lesende können höchstens kommentieren, ältere Beiträge werden nicht weiter gepflegt. Für das Barcamp 2028 braucht das Team aber ein aktuelles Nachschlagewerk („Wie läuft der Check-in?“), keinen Verlauf von Berichten. Ein Blog eignet sich eher für Neuigkeiten auf der öffentlichen Website.

Je Risiko 1 Punkt für das Risiko und 2 Punkte für eine passende, beschriebene Maßnahme. Zwei aus z. B.:

• Veraltete oder falsche Inhalte: Seiten werden nach dem Barcamp nicht aktualisiert, 2028 arbeitet das Team mit falschen Angaben (z. B. alte VLAN-Nummern). Maßnahme: Für jeden Bereich (Technik, Catering, Sessionplanung, Helfende) ist eine Person verantwortlich; jede Seite hat ein Prüfdatum; vier Wochen nach dem Barcamp gibt es eine feste Aufräumrunde.

• Wildwuchs und schlechte Auffindbarkeit: Jede*r legt Seiten nach eigenem Schema an, Inhalte sind doppelt. Maßnahme: Dimitrios Papadopoulos gibt vor dem Start eine Startseite mit Bereichen, Namensregeln und Vorlagen (Checkliste, Anleitung, Protokoll, Lessons Learned) vor.

• Geringe Beteiligung: Viele lesen, kaum jemand schreibt; Lehrkräfte sehen das Wiki als Mehrarbeit. Maßnahme: kurze Einführung beim Kick-off, Startinhalte vorab einpflegen, Wiki in Abläufe einbinden („Eine Aufgabe gilt erst als erledigt, wenn die Anleitung im Wiki steht“).

• Datenschutz und Sicherheit: Telefonnummern von Referierenden oder MQTT-Zugangsdaten landen auf Seiten, die viele lesen; gelöschte Angaben bleiben in der Versionsgeschichte. Maßnahme: Regel „keine Zugangsdaten, nur nötige personenbezogene Daten“, Rechte je Bereich, Zugangsdaten im Passwortmanager der Schul-IT, endgültiges Löschen von Versionen durch die Administration.

• Pflegeaufwand nach dem Weggang der Azubis: Niemand fühlt sich 2028 zuständig. Maßnahme: Übergabe der Bereichsverantwortung an Schüler*innen eines jüngeren Jahrgangs schon im Frühjahr 2027.

Je Zeile 1 Punkt:

Andere passende Funktionen (z. B. Suche, Vorlagen, Diskussionsseite) sind zu werten, wenn sie die Anforderung erfüllen.

Ein CMS ist eine Software, mit der man digitale Inhalte (Texte, Fotos, Videos, Downloads) einer Website erstellen, verwalten und veröffentlichen kann (1 Punkt), ohne Programmier- oder HTML-Kenntnisse zu brauchen – die Redaktion arbeitet in einer Oberfläche im Browser (1 Punkt).

• Trennung (1 Punkt): Inhalte werden in der Datenbank gespeichert, das Aussehen wird getrennt davon in Themes (Vorlagen) festgelegt. Die Schule kann das Layout austauschen, ohne Inhalte anzufassen, und Redakteur*innen müssen sich beim Schreiben nicht um die Gestaltung kümmern.

• Dashboard (Bearbeitungsanwendung, Content Management Application, Backend) (1 Punkt): Oberfläche für die Redaktion im Browser; dort werden Texte geschrieben, Fotos und Videos hochgeladen und der Platz im Menü festgelegt.

• Delivery engine (Auslieferungsanwendung, Content Delivery Application, Frontend) (1 Punkt): Ruft jemand eine Seite auf, holt sie den Inhalt aus der Datenbank, setzt ihn in das aktive Theme ein und liefert die fertige HTML-Seite aus (dynamische Seitenerzeugung).

Je CMS 0,5 Punkte, Wiki-Software 1 Punkt.

• CMS z. B.: WordPress, TYPO3, Joomla, Drupal (auch Baukästen wie Wix oder Headless-CMS wie Strapi sind zu werten).

• Wiki-Software z. B.: MediaWiki, DokuWiki, BookStack, Wiki.js, XWiki, Confluence.

Je Funktion 1 Punkt für die Beschreibung, 1 Punkt für den Nutzen mit Bezug zum Barcamp. Vier aus z. B.:

• Vorlagen für Seitentypen: Das CMS stellt vorgefertigte Vorlagen für Seitenarten bereit, die nur ausgefüllt werden. Jede Session-Seite (Titel, Referierende, Raum, Slot, Kurzbeschreibung, Folien, Video) sieht gleich aus, auch wenn sieben verschiedene Schüler*innen sie anlegen.

• Rollen- und Rechteverwaltung (redaktionelle Hierarchie): Benutzer*innen erhalten Rollen wie Autor*in, Redaktion und Freigabe mit unterschiedlichen Rechten. Schüler*innen dürfen Nachberichte schreiben, aber nur Dimitrios Papadopoulos prüft und nur die Schulleitung veröffentlicht – die Schule bleibt als Betreiberin verantwortlich.

• Versionsverwaltung: Jede Änderung einer Seite wird als Version gespeichert und lässt sich vergleichen oder zurücknehmen. Wird der Sessionplan am 01.03.2027 versehentlich überschrieben, ist der alte Stand schnell wiederhergestellt.

• Workflow und zeitgesteuerte Veröffentlichung: Inhalte durchlaufen Entwurf, Prüfung und Freigabe; der Veröffentlichungszeitpunkt lässt sich planen. Der Sessionplan wird vorbereitet und erscheint automatisch am 01.03.2027; der Call for Participation verschwindet nach dem 31.01.2027 von selbst.

• Medienverwaltung: Bilder, Folien (PDF) und Videos werden zentral mit Metadaten abgelegt, das CMS erzeugt passende Bildgrößen. Folien der Referierenden lassen sich mehreren Seiten zuordnen; Pflichtfelder für Alternativtexte und Bildrechte unterstützen Barrierefreiheit und Datenschutz.

• Erweiterungen (Plugins): Zusatzfunktionen werden ohne Programmierung nachgerüstet, z. B. ein Veranstaltungskalender, ein Kontaktformular oder ein Video-Player mit Untertiteln (z. B. für gehörlose Referierende und Teilnehmende).

• Navigation und Struktur: Menüpunkte und Seitenbaum entstehen aus den Inhalten; der Barcamp-Bereich erscheint automatisch im Menü der Schulwebsite.

Bewertungshinweis: Nur genannte Funktionen („Versionierung“) ohne Beschreibung je 0,5 Punkte.

Je Station 1 Punkt:

Statt der Schulleiterin ist auch eine andere verantwortliche Person (z. B. Website-Verantwortliche der Schule) richtig, wenn Prüfung und Freigabe getrennt sind.

• Spätestens bei der Prüfung (Station 2) muss Dimitrios Papadopoulos die Fotoeinwilligungen mit den Anmeldedaten abgleichen (1 Punkt). Besser schon beim Hochladen: Das Pflichtfeld „Einwilligung liegt vor“ in der Medienverwaltung zwingt die Autorin, die Einwilligung zu prüfen.

• Umgang (1 Punkt): Das Foto wird nicht veröffentlicht, durch ein anderes ersetzt oder Fatma wird unkenntlich gemacht (Bildausschnitt, Verpixeln). Ohne Einwilligung bzw. andere Rechtsgrundlage dürfen personenbezogene Daten wie ein erkennbares Foto nicht veröffentlicht werden (DSGVO, Kunsturhebergesetz); bei Minderjährigen ist besondere Vorsicht geboten. Wird das Foto erst später entdeckt, reicht Löschen von der Seite nicht: auch alte Versionen und Bildgrößen in der Medienverwaltung entfernen.

Zwei Gründe à 1 Punkt, z. B.:

• Im Wiki dürfen alle Beteiligten ohne vorherige Prüfung ändern; für öffentliche Inhalte, für die die Schule verantwortlich ist, braucht es eine Freigabe durch eine verantwortliche Person (Workflow im CMS).

• Das Orga-Wiki enthält interne Informationen (Notfallkontakte, Netzplan, Zugangswege), die nicht öffentlich sein dürfen.

• Die Barcamp-Seite soll im Design der Schulwebsite erscheinen (Themes, Navigation); ein Wiki ist schlicht gestaltet und als Nachschlagewerk aufgebaut.

• Funktionen für Besucher*innen wie Veranstaltungskalender, Kontaktformular und zeitgesteuerte Veröffentlichung bietet das CMS.

• Grund gegen ein CMS (1 Punkt): Die Projektseite ändert sich kaum. Bei seltenen Änderungen lohnt sich ein CMS nicht; Installation, Updates und Absicherung kosten mehr, als die Redaktion spart. Statische Seiten sind schneller, günstiger und bieten weniger Angriffsfläche.

• Barcamp-Bereich (2 Punkte): Die Inhalte ändern sich häufig (Call for Participation, Sessionplan mit Verschiebungen, Nachberichte, Folien, Videos), und viele Personen ohne HTML-Kenntnisse schreiben mit (Schüler*innen, Referierende, Orga-Team). Inhalte müssen vor der Veröffentlichung geprüft werden (Datenschutz, Fotoeinwilligungen). Das CMS läuft ohnehin schon für die Schulwebsite und wird von der Schul-IT gewartet – zusätzlicher Betriebsaufwand entsteht kaum. Deshalb ist das CMS hier die bessere Wahl.

Bewertungshinweis: Eine gut begründete abweichende Entscheidung (z. B. statischer Seitengenerator mit Markdown und Git, weil das Software-Team ohnehin mit Git arbeitet) ist mit voller Punktzahl zu werten, wenn Änderungshäufigkeit und Freigabe berücksichtigt werden.

Je richtiger Zuordnung 1 Punkt:

Übrig bleiben ERP (Enterprise Resource Planning, Planung von Ressourcen wie Material, Personal, Finanzen) und CAD (Computer-Aided Design, rechnergestütztes Konstruieren).

Je Angebot 2 Punkte für eine sinnvolle, auf die Situation bezogene Begründung. Naheliegend:

Andere Auswahl mit guter Begründung ist zu werten. Weniger geeignet: FAQ auf der öffentlichen Seite (richtet sich an Teilnehmende, nicht an Helfende; interne Abläufe gehören nicht in die Öffentlichkeit), Chatbot (Aufwand für einen einzigen Tag, Antworten ggf. ungeprüft), gedrucktes Handbuch (nicht aktuell, am Stand unhandlich; höchstens als einseitige Notfallkarte bei Netzausfall sinnvoll).