Mitwirken (Contributing)

Diese Seite richtet sich an Leute, die aktiv am Projekt mitentwickeln möchten. Sie ergänzt README.md (Code-Repo) um projekt-spezifische Regeln/Workflows.

Grundprinzip: Quelle der Wahrheit

• Code-Verhalten: im Repo zgb_www/ (Quellcode).
• Offene Aufgaben: zgb_www/todo.md (nicht im Wiki duplizieren).
• Wiki: langlebiges Wissen, Erklärungen, Betriebsanleitungen.

Siehe auch: Roadmap, Projekt-Landkarte

Schnellstart für Entwickler

• Setup/Build/Server: Lokale Entwicklung
• Tests ausführen/erweitern: Tests
• System-Überblick: Projekt-Landkarte
• Mail-Queue Mechanik: Mail-Queue
• Performance-Überblick: Performance & Optimierungen
• Begriffe: Glossar

Wo ändere ich was? (Orientierung)

• Inhalte/Seiten: zgb_www/content/ + content/pages.json + content/globals.json
  • Danach: Build laufen lassen.
• Statische Assets: zgb_www/static/assets/ (CSS/JS/Bilder)
  • Danach: Build laufen lassen.
• Öffentliche PHP-Endpunkte: zgb_www/static/*/*.php (z.B. /anmeldung/, /registration/, /api/…)
  • Danach: Build laufen lassen (kopiert nach public/).
• Backend (Services/Repos/Admin): zgb_www/zgb-backend/
  • Danach: Build laufen lassen (kopiert nach public/backend/).
• DB-Schema: zgb_www/zgb-backend/Repository/Schema/*

Entwicklungs-Workflow (empfohlen)

1. Kleine, thematisch klare Änderungen (1 Problem = 1 PR).
2. Änderungen lokal bauen und kurz testen.
3. PR beschreiben: Was/Warum, ggf. Link auf Wiki-Seite oder Code-Stelle.

“Definition of Done” (für PRs)

• Änderung ist verständlich (kurzer Kommentar oder Wiki-Update, wenn nötig).
• Build läuft (npm run build) und das Ergebnis verhält sich korrekt.
• Falls Backend betroffen:
  • Admin/Login/Anmeldung nicht kaputt
  • DB-Schema kompatibel (oder Migration/Kommentar)
• Keine Secrets im Code.

Tests (wo vorhanden)

Im Repo gibt es zgb_www/tests/ und Runner-Skripte (siehe Code-Repo).
Wenn du Tests anfasst: Fokus auf “kritische Flows” (Anmeldung, Admin-POSTs, Mail-Queue Worker/Repo).

Stil & Konventionen (praktisch)

• Keine Duplikation von Wissen:
  • Wiki erklärt “Warum/Wie” und verweist auf Code.
  • Tasks bleiben in todo.md/Issues.
• Paths immer relativ zu public/ denken:
  • “Was der Server wirklich ausführt” liegt unter public/ (Build-Output).
• Sicherheit:
  • POSTs: CSRF prüfen, Session via SessionService.
  • Mail: Header-Injection-Schutz nicht umgehen.