Plan: Veranstaltungen Option C — Strukturierte Event-QMD-Dateien

Stand: 2026-06-12
Status: Reserviert — Ausbau wenn Veranstaltungsvolumen steigt (Richtwert: >10 Termine/Jahr)
Aktuell im Einsatz: Option B (Include-Fragment + manuelles Listing)

Motivation

Option B pflegt anstehende Termine als HTML-Fragment und Berichte als explizite Listing-Pfade. Das reicht für kleine Volumina. Ab ~10 Veranstaltungen pro Jahr lohnt sich eine strukturierte Datei pro Event mit eigenem Frontmatter und zwei automatischen Listings (anstehend/vergangen).

Zielstruktur

veranstaltungen/
  index.qmd                   # Übersichtsseite (2 Listings: anstehend + vergangen)
  _upcoming.qmd               # bleibt: Fragment für Homepage-Include
  anstehend/
    _metadata.yml             # draft: false, toc: false, event_status: upcoming
    2026-07-09-fex-staatsverstaendnis.qmd
    2026-09-23-fex-neue-akteure.qmd
  vergangen/
    _metadata.yml             # draft: false, toc: false, event_status: past
    2026-06-20-fex-funktionserhalt.qmd
    2025-12-26-dialogforum-9.qmd
    2026-05-30-impulse-echte-maenner.qmd

Frontmatter-Schema für Event-Dateien

---
title: "FEX-Online-Lunch: Die gespaltene Realität"
description: "Strukturelle Divergenzen im Staatsverständnis – Vortrag und Diskussion."
date: "2026-07-09"            # Veranstaltungsdatum (= Quarto-Sortierdatum)
event_date: "2026-07-09"      # explizit, falls Veröffentlichungsdatum abweicht
event_location: "Online"
event_type: "Vortrag"         # Vortrag | Workshop | Podium | Moderation | Seminar
event_series: "FEX"           # optional: Reihe oder Auftraggeber
event_status: "upcoming"      # upcoming | past
report_url: ""                # nach dem Termin: URL zum Veranstaltungsbericht
draft: false
---

Kurze Beschreibung der Veranstaltung, Zielgruppe, Thema.

Listings in veranstaltungen/index.qmd

listing:
  - id: anstehend
    contents: anstehend
    type: default
    sort: "date asc"
    fields: [date, title, description]
    filter-ui: false
    sort-ui: false

  - id: vergangen
    contents: vergangen
    type: default
    sort: "date desc"
    fields: [date, title, description]
    filter-ui: false
    sort-ui: false

Migration von Option B nach Option C

  1. Bestehende Berichte aus publikationen/posts/ mit Veranstaltung-Kategorie bleiben dort — die Event-QMD-Datei unter vergangen/ verlinkt per report_url darauf.
  2. _upcoming.qmd wird weiterhin gepflegt und per Include auf der Homepage eingebunden — zusätzlich kann das Listing anstehend/ die gleichen Termine als strukturierte Daten liefern.
  3. Wenn ein Termin vorbei ist: Datei von anstehend/ nach vergangen/ verschieben, event_status: past setzen, report_url ergänzen (falls Bericht vorhanden).

Wann umstellen?

  • Mehr als 10 Termine/Jahr
  • Bedarf an strukturierten Metadaten (Ort, Typ, Reihe) in Listings oder für SEO
  • Externe Tools (z. B. ContentPilot) sollen Events automatisch anlegen

Bis dahin: Option B ist ausreichend und deutlich weniger Pflegeaufwand.