Hier definieren wir erforderliche "Definition of Done" (DoD) Kriterien für einen PR, damit dieser für den Review und ggf. Merge zugelassen werden kann.

Brainstorming aus Paretz:

Allgemein/PRs

Neue PRs werden bei der Erstellung automatisch mit einem DoD Protokoll erstellt. Dieses muss vom PR-Ersteller abgearbeitet werden, bevor das WIP Label entfernt und damit der Review angefragt werden kann.

• Links zu verwandten PRs anderer Repositories 
• Link zum Ticket (URL vorbereitet)
  • Im Ticket (Oder im PR, wenn kein Ticket): Beschreibung (und Begründung) der Änderung/Neuerungen
• Neuer PR ist automatisch mit dem Label WIP versehen
• Review darf eröffnet werden, wenn alle DoD Punkte erfüllt sind. Review wird eingeleitet durch Zuweisen der Reviewer und Entfernen des WIP-Labels
  
  • Review Datenschutz → Release-Informationen bei Datenbankänderung oder Seed-Änderung (Datenschutzgruppe wird automatisch hinzugefügt)
• Ein Mitglied der Gruppe "Review-..." muss den PR genehmigen, wird automatisch hinzugefügt

Tests

• Keine Codecoverage Verringerung, Codecov verhindert Merge (Martin)
• Bei neuen Features: Unit-Tests und Integrations-Tests schrieben (oder bei bestehenden, wenn keine Tests vorhanden)
• Keine offenen bekannten Bugs im entwickelten Code

Dokumentation

• Swagger (Server) - wenn API Änderungen vorgenommen wurden
• Storybook (Client) - wenn neue UI Atome hinzugefügt wurden
• Neue Abhängigkeiten (Repos, NPM Pakete, Vendor Skripte) begründen und überprüfen (Stabilität, Performance, Aktualität, Autor)
• Übergabe/Schulung & Administrationsinfos (#Busfaktor, Confluence intern)
• Gibt es wichtige User-Infos (Confluence öffentlich)
• Müssen Guides/Hilfe aktualisiert werden?
• Release Notes - wenn es sich um große Feature-Releases handelt
• Changelog-Eintrag in der CHANGELOG.md des Projektes nach folgenden Regeln (siehe SOP: Changelog)

Datenschutz

• Model-/Seedänderungen erfordern Review der Datenschutz-Gruppen (wird automatisch hinzugefügt)
• Wenn personenbezogene Daten neu verarbeitet werden, muss das mit der Datenschutz-Gruppe besprochen werden

Code- und UI-Qualität

• Keine Linter Probleme, Github prüft automatisch neuen Code auf Linter
• Code immer mit Hinblick auf Security und Datensicherheit achten
• Kernlogik im API programmiert?
• Bei UI Änderungen: Review mit einer Frontend/UI/Design-Person durchgeführt?

Deployable

• Feature Toggle notwendig?
• Datenbankanpassungen notwendig? / Migrationsskripte
  • Alle DB-Anpassungen müssen in den Seed-Daten reflektiert werden
• Neue Konfiguration an der Architektur/Hardware
• Neue Berechtigungen/Rollen, Änderungen der Zugriffe auf Basis dieser