Pull-Request-Limits auf GitHub: Weniger Spam, mehr Fokus für Maintainer

Die Open-Source-Welt wächst rasant – und mit ihr die Flut an Pull Requests. Täglich landen unzählige Änderungen in Projekt-Repositories, doch die meisten Maintainer können diese schlicht nicht mehr bewältigen. GitHub reagiert nun mit einer einfachen, aber wirksamen Lösung: Pull-Request-Limits. Diese neue Funktion begrenzt die Anzahl gleichzeitig offener Pull Requests für Nutzer ohne Schreibrechte. Doch wie genau funktioniert das, und warum ist es gerade jetzt so wichtig?

Warum GitHub die Limits einführt – und warum jetzt

Seit Jahren steigt die Zahl der Pull Requests auf GitHub kontinuierlich an. Im Januar 2023 wurden monatlich etwa 25 Millionen Pull Requests gemergt. Heute sind es bereits über 90 Millionen – eine Steigerung um das 3,6-fache. Dieser Anstieg ist vor allem auf zwei Faktoren zurückzuführen:

• Einfachere Erstellung: Tools wie GitHub Copilot und KI-gestützte Codegeneratoren ermöglichen es selbst weniger erfahrenen Entwicklern, schnell Pull Requests zu erstellen.
• Wachsende Community: Immer mehr Projekte ziehen neue Mitwirkende an, die oft aus Begeisterung oder Neugier beitragen – manchmal jedoch ohne ausreichende Qualitätssicherung.

Das Problem: Die Review-Kapazität der Maintainer bleibt unverändert. Ein menschlicher Reviewer braucht heute noch genauso lange wie vor Jahren, um einen Pull Request zu prüfen. Wenn jedoch Dutzende oder gar Hunderte unfertige oder irrelevante Requests in der Warteschlange landen, wird es unmöglich, die wirklich wertvollen Beiträge zu erkennen.

GitHubs neue Pull-Request-Limits sollen hier Abhilfe schaffen. Sie geben Maintainern die Kontrolle zurück, die sie sich seit Langem gewünscht haben – ohne die Tür für neue Mitwirkende zu schließen.

So funktionieren die neuen Limits – und wer betroffen ist

Die neue Funktion setzt eine klare Grenze: Nutzer ohne Schreibrechte dürfen maximal eine bestimmte Anzahl an Pull Requests gleichzeitig offen haben. Sobald diese Grenze erreicht ist, müssen sie einen bestehenden Request schließen oder mergen, bevor sie einen neuen erstellen können.

Wichtige Details im Überblick:

• Betrifft nur Nutzer ohne Schreibrechte: Entwickler mit vollen Zugriffsrechten auf ein Repository sind von den Limits ausgenommen.
• KI-generierte Pull Requests zählen mit: Auch Requests, die von Tools wie GitHub Copilot oder anderen KI-Agenten erstellt wurden, fallen unter die Limits.
• Draft-Pull-Requests bleiben unberücksichtigt: Noch nicht fertige Requests, die als Entwurf markiert sind, werden nicht auf die Limit-Zählung angerechnet.
• Ausnahmen möglich: Vertrauenswürdige Mitwirkende können auf eine Bypass-Liste gesetzt werden. Sie sind dann von den Limits ausgenommen, erhalten aber keinen vollen Schreibzugriff auf das Repository.

Diese Limits unterscheiden sich von den bereits bestehenden Interaktionssperren, die bisher nur temporäre Cooldowns vorsahen. Die neuen Regeln sind persistent und einstellbar – genau das, was Maintainer sich gewünscht hatten.

Wie sich das Verhalten der Mitwirkenden ändert

Eine der größten Herausforderungen für Maintainer war bisher, dass jede:r Nutzer:in innerhalb von Sekunden einen Pull Request erstellen konnte – egal, ob es sich um eine hochwertige Änderung oder einen schlechten Entwurf handelte. In der Warteschlange sahen beide gleich aus, und die Auswahl der wirklich relevanten Requests wurde zur Sisyphusarbeit.

Die neuen Limits zwingen Mitwirkende dazu, bewusster zu handeln:

• Statt fünf halbfertige Pull Requests gleichzeitig zu öffnen, müssen sie sich auf eine oder zwei hochwertige Änderungen konzentrieren.
• Die erste Qualitätsprüfung findet bereits vor dem Öffnen eines Requests statt – eine kleinere Warteschlange macht es leichter, gute Arbeit zu erkennen.
• Maintainer erhalten weniger Spam und irrelevante Requests, sodass sie sich auf die wirklich wichtigen Beiträge konzentrieren können.

Stimmen aus der Community: Warum die Limits funktionieren

Die Reaktionen von Maintainern, die die neuen Limits bereits testen, sind überwiegend positiv:

„Es ermutigt uns wieder, Pull Requests zu reviewen. Wenn jemand nicht einfach fünf bis zehn halbfertige Requests geöffnet hat, macht es viel mehr Spaß, sich die Änderungen anzusehen. Langfristig hilft uns das, unseren Rückstand abzubauen und sicherzustellen, dass wir genau das reviewen, was wir wirklich brauchen.“ — Nicholas Tindle, AutoGPT

„Dieses Feature ist großartig. Bei Homebrew hatten wir lange das Problem, dass begeisterte Mitwirkende zahlreiche ähnliche Pull Requests einreichten – oft mit geringfügigen Änderungen. KI hat das noch beschleunigt. Jetzt können wir weiterhin externe Beiträge begrüßen, während wir die Zahl der Requests auf ein handhabbares Maß begrenzen.“ — Mike McQuaid, Homebrew

„Bei OpenClaw erhalten wir eine riesige Menge an Pull Requests aus der Community. Bisher mussten wir eigene Bots entwickeln, um Spam zu bekämpfen. Jetzt freuen wir uns, dass GitHub Maintainern standardmäßig Werkzeuge an die Hand gibt, um diese Flut zu bewältigen.“ — Vincent Koc, OpenClaw

Was als Nächstes kommt: Mehr Kontrolle über Beiträge

Die Pull-Request-Limits sind erst der Anfang. GitHub plant bereits weitere Funktionen, um die Verwaltung von Beiträgen noch flexibler zu gestalten:

Geplante Features im Überblick:

Archivierung von Pull Requests (bald verfügbar)

• Repository-Admins können Pull Requests archivieren, um sie aus der Hauptansicht zu entfernen.
• Archivierte Requests bleiben für Admins zugänglich, sind aber standardmäßig ausgeblendet.
• Keine Löschung: Viele Organisationen dürfen Pull Requests aus rechtlichen Gründen nicht dauerhaft entfernen – die Archivierung bietet eine Lösung.

Issue-Limits (in Entwicklung)

• Ähnliche Limits wie bei Pull Requests werden auch für Issues eingeführt.
• Nutzer ohne Schreibrechte dürfen nur eine bestimmte Anzahl offener Issues gleichzeitig haben.
• Eine Bypass-Liste ist ebenfalls vorgesehen, ebenso wie die Option, die Erstellung von Issues auf Collaborators zu beschränken.

Intelligentere Bypass-Signale (demnächst)

• Statt manuell vertrauenswürdige Mitwirkende auf eine Liste zu setzen, sollen automatische Signale entscheiden, wer von den Limits ausgenommen wird.
• Mögliche Kriterien:
• Bereits gemergte Pull Requests im Repository
• Alter des Nutzerkontos
• Zugehörigkeit zu einer Organisation

Cross-Repository-Kontrollen (in Erprobung)

• Bisher beschränken sich die Limits auf ein einzelnes Repository.
• Doch was ist, wenn jemand Pull Requests in Hunderten von Repositories gleichzeitig öffnet?
• GitHub arbeitet an Lösungen, um solche Spam-Aktivitäten zu erkennen – sei es durch Trust-Signale, Rate-Limits oder andere Mechanismen.

Ein Dank an die Open-Source-Community

Open Source lebt von den Menschen, die jeden Tag Zeit und Energie investieren – sei es beim Reviewen von Pull Requests, beim Mentoring neuer Mitwirkender oder beim Organisieren von Issues. Euer Feedback hat diese Funktion erst möglich gemacht.

GitHub betont, dass die neuen Limits nur ein erster Schritt sind. Die Plattform wird weiterhin mit der Community zusammenarbeiten, um Tools zu entwickeln, die Maintainern helfen, ohne gute Beiträge zu blockieren.

Die neuen Pull-Request-Limits können direkt in den Repository-Einstellungen aktiviert werden. Probieren Sie es aus und geben Sie Feedback – es ist entscheidend für die Weiterentwicklung. Vielleicht sieht man sich ja bald wieder in der Pull-Request-Warteschlange. 🧡