Contributor Guide

So shippst du deinen ersten Pull Request

Der kürzeste verlässliche Weg vom einsteigerfreundlichen Issue bis zum gemergten maintainer-ready Pull Request.

Hier starten

Wähle dein Startlevel

Nutze diese Karten als statischen Selector. Wähle die Karte, die zu deinem aktuellen Stand passt, und folge danach denselben Phasen unten.

Kompletter Einsteiger

Starte mit Tools, Vokabular und einer reinen Dokumentationsänderung. Dein Ziel ist, eine sichere Schleife abzuschließen.

Erste PR überhaupt

Wähle ein winziges, aktuelles Issue und halte den Diff fokussiert. Frag nach Bestätigung, bevor du codest.

Wiederkehrender Contributor

Nutze das Playbook als Checkliste und stecke den Großteil deiner Energie in Reproduktion und Tests des Fixes.

Phase 0

Basistools installieren

Du brauchst nur genug lokale Tools, um das Repository zu clonen, einen Branch zu erstellen, Projektchecks auszuführen und deine Arbeit zu pushen.

git

Git verfolgt deine Arbeit und lässt Maintainer exakt reviewen, was sich geändert hat.

git --version

gh

GitHub CLI hilft dir beim Forken, Clonen, Authentifizieren und Öffnen von Pull Requests, ohne das Terminal zu verlassen.

gh auth login
gh repo fork OWNER/REPO --clone --remote

editor

Nutze einen Editor, der das ganze Repository durchsuchen, Formatter ausführen und geänderte Dateien klar anzeigen kann.

code .

Phase 1

Das richtige Issue wählen

Ein gutes first issue ist nicht nur klein. Es ist aktuell, verständlich und von jemandem reviewbar, der das Projekt bereits maintained.

Übernehmen

Hinterlasse einen kurzen Kommentar, der das konkrete Issue nennt und fragt, ob der Scope noch Sinn ergibt.

Regeln lesen

Lies CONTRIBUTING, README, offene Pull Requests, Testbefehle und Code-Style-Hinweise, bevor du Code änderst.

Fork + Branch

Erstelle deine eigene Kopie und arbeite auf einem Branch, der nach dem Task benannt ist, nicht auf main.

Setup + Reproduktion

Installiere Dependencies, reproduziere das Problem und notiere den Befehl oder Screen, auf dem du es gesehen hast.

Winzigen Diff shippen

Ändere so wenig Code wie nötig. Vermeide Drive-by-Refactors, Dependency-Upgrades und unrelated Formatting.

PR öffnen

Erkläre, was sich geändert hat, wie du getestet hast und welche Grenzen es gibt. Mach den ersten Review-Durchgang leicht.

Stopppunkte

Warnsignale, bevor du mehr Zeit investierst

Früh zu stoppen ist besser, als einen Pull Request zu erzwingen, der nicht reviewbar ist.

Du kannst das Projekt nach dem dokumentierten Setup nicht lokal ausführen.

Du kannst das Projekt nach dem dokumentierten Setup nicht lokal ausführen.

Der Fix erfordert, Produktverhalten ohne Maintainer-Input zu erraten.

Der Fix erfordert, Produktverhalten ohne Maintainer-Input zu erraten.

Das Issue verlangt ein großes Feature, Redesign, eine Migration oder Architekturentscheidung.

Das Issue verlangt ein großes Feature, Redesign, eine Migration oder Architekturentscheidung.

Ein Maintainer hat First-Time Contributors gebeten, nicht an diesem Bereich zu arbeiten.

Ein Maintainer hat First-Time Contributors gebeten, nicht an diesem Bereich zu arbeiten.

Referenz

Glossar

Fork
Deine persönliche Kopie eines Repositorys. Du pushst deinen Branch dorthin, bevor du einen Pull Request öffnest.
Branch
Eine bewegliche Arbeitslinie. Nutze einen Branch pro Issue, damit deine Änderungen reviewbar bleiben.
Pull request
Eine Anfrage an Maintainer, deinen Branch zu reviewen und in das Projekt-Repository zu mergen.
Diff
Die kleinste sinnvolle Änderungsmenge, die das Issue löst, ohne unrelated Cleanup.
CONTRIBUTING
Eine projektspezifische Checkliste für Setup, Style, Tests und Pull-Request-Erwartungen.

FAQ

Häufige Fragen zur ersten PR

Was, wenn der Maintainer seit einer Woche nicht geantwortet hat?

Poste ein kurzes Follow-up mit deinem aktuellen Stand und einer direkten Frage. Wenn weiterhin keine Antwort kommt, wähle ein anderes Issue, statt unbegrenzt zu warten.

Was soll ich tun, wenn das Setup fehlschlägt?

Sag, was du versucht hast, füge den exakten Fehler ein, nenne Betriebssystem und Tool-Versionen und frag nach dem nächsten Debugging-Schritt.

Kann meine erste PR nur Dokumentation sein?

Ja, wenn das Repository Dokumentationsänderungen begrüßt. Klare Docs, Beispiele, Tippfehler und defekte Links sind legitime Beiträge.