Pull Requests, die ankommen

Dein Code ist fertig, die Tests laufen, der Branch ist gepusht. Jetzt kommt der Moment der Wahrheit: der Pull Request. Ein guter PR wird in Stunden gemergt. Ein schlechter liegt wochenlang unbeachtet — oder wird direkt geschlossen.

🔄 Quick Recall: In der letzten Lektion hast du den Git-Workflow gelernt — Fork, Branch, Commit, Push. Jetzt machst du aus deinem Branch einen PR, den Maintainer gerne reviewen.

Anatomie eines guten Pull Requests

Bestandteil	Was gehört rein	Warum
Titel	Kurz, beschreibend, Imperativ	Maintainer scannt Titel zuerst
WAS	Zusammenfassung der Änderung	Kontext auf einen Blick
WARUM	Problem, das gelöst wird	Begründung für die Änderung
WIE TESTEN	Schritte zum Reproduzieren	Maintainer will testen können
Screenshots	Bei UI-Änderungen	Visueller Beweis
Issue-Referenz	`Fixes #42` oder `Closes #42`	Automatisches Issue-Schließen

KI-Prompt für PR-Beschreibungen:

„Schreibe eine Pull-Request-Beschreibung für folgenden Diff: [Diff einfügen]. Struktur: ## What (kurze Zusammenfassung), ## Why (Problem und Lösung), ## How to Test (Schritte), ## Related (Issue-Referenz). Halte es prägnant."

Self-Review: Vor dem Einreichen

Bevor du auf „Create Pull Request" klickst, mach ein Self-Review. Puh, das klingt nach Extra-Arbeit — aber es spart dir und den Maintainern Stunden.

Self-Review-Checkliste:

□ Tests laufen lokal (alle grün?)
□ Linter/Formatter laufen ohne Fehler
□ Diff durchgegangen — keine Debug-Prints, keine TODO-Kommentare
□ CONTRIBUTING.md-Anforderungen geprüft
□ Commit-Messages sauber (Imperativ, WARUM, Issue-Referenz)
□ Branch auf aktuellem Upstream basiert (kein Merge-Conflict)

KI-Prompt für Self-Review:

„Reviewe diesen Diff als wärst du ein erfahrener Maintainer. Finde: 1) Logik-Fehler, 2) Stil-Verletzungen, 3) fehlende Tests, 4) Sicherheitsprobleme, 5) Performance-Issues. Sei kritisch."

✅ Quick Check: Du hast einen PR fertig und bemerkst beim Self-Review, dass du einen console.log("debug") vergessen hast. Was machst du? (Antwort: Entfernen, neuen Commit, pushen. Debug-Ausgaben im PR sind unprofessionell und zeigen Maintainern, dass du kein Self-Review machst.)

Mit Feedback umgehen

Feedback von Maintainern ist keine Kritik — es ist eine Lernchance. Die kennen ihre Codebase besser als du.

Feedback-Typ	Richtige Reaktion
Stiländerung	Sofort umsetzen, Projekt-Konventionen gelten
Architekturvorschlag	Verstehen (KI fragen), umsetzen, nachfragen wenn unklar
Grundsätzliche Ablehnung	Professionell akzeptieren, fragen ob alternativer Ansatz möglich
Keine Reaktion	1 Woche warten, dann höflich pingen

KI-Prompt für Feedback-Verständnis:

„Ein Maintainer hat dieses Review-Feedback gegeben: [Feedback einfügen]. Erkläre mir, was genau gemeint ist und wie ich die Änderung umsetze."

Wichtig für Deutschland: Die meisten großen Open-Source-Projekte kommunizieren auf Englisch. Auch deutsche Projekte wie Nextcloud oder OpenProject haben englischsprachige GitHub-Kommunikation. Dein PR und deine Antworten sollten auf Englisch sein — außer das Projekt kommuniziert explizit auf Deutsch.

✅ Quick Check: Ein Maintainer antwortet auf deinen PR: „LGTM, but please squash your commits before merging." Was bedeutet das? (Antwort: LGTM = Looks Good To Me — dein Code ist akzeptiert! „Squash" bedeutet: Mehrere Commits zu einem zusammenfassen mit git rebase -i. Das hält die Git-History sauber.)

PR-Etikette

Regel	Warum
Antworte innerhalb von 48h auf Feedback	Zeigt Engagement, hält den PR aktiv
Bedanke dich für Reviews	Maintainer arbeiten oft ehrenamtlich
Erkläre deine Entscheidungen, wenn gefragt	Hilft beim Verständnis und baut Vertrauen auf
Akzeptiere Ablehnungen professionell	Nicht jeder PR passt — das ist okay
Ein PR = eine Änderung	Kein Feature-Creep in bestehenden PRs

Draft PRs — Frühes Feedback holen

Nicht sicher, ob dein Ansatz richtig ist? Erstelle einen Draft PR:

1. PR erstellen → "Create draft pull request" wählen
2. In der Beschreibung: "WIP: Feedback gewünscht zu [Ansatz]"
3. Maintainer können früh kommentieren
4. Nach Feedback: Änderungen machen → "Ready for review" klicken

Draft PRs sind besonders bei größeren Änderungen sinnvoll — du investierst nicht Tage in einen Ansatz, den die Maintainer ablehnen.

Key Takeaways

PR-Beschreibung: WAS, WARUM, WIE TESTEN, Screenshots, Issue-Referenz
Self-Review vor dem Einreichen — KI hilft bei der Code-Analyse
Feedback ist Lernchance — Maintainer kennen ihre Codebase
Draft PRs für frühes Feedback bei unsicherem Ansatz
Kommunikation in Open Source ist meist auf Englisch — auch bei deutschen Projekten

Up Next

In der nächsten Lektion geht es um Beiträge jenseits von Code — Dokumentation, Übersetzung, Issue Triage und Community-Arbeit.