So sanft wie möglich, so hart wie nötig

GitHub-Etikette: Über den Umgang mit Pull Requests

Michael Thomas

© Shutterstock.com/GongTo

Gerade zu Beginn eines Projekts kann jeder Pull Request Gold wert sein. Doch was tun, wenn – zumeist aus Gründen gestiegener Popularität eines Projekts – die Frequenz und Qualität der Pull Requests langsam aber sicher Probleme bereitet? Die Repository-Plattform hat einen kleinen Leitfaden für den Umgang mit derartigen Fällen zusammengestellt.

Vermutlich jeder Maintainer eines Projekt, das eine gewisse Traktion gewonnen hat, wird über kurz oder lang von einer Flut an Pull Requests konfrontiert. Was vormals eine Hilfe war, wird so leicht zu einer nicht zu unterschätzenden Belastung. Der GitHub-Mitarbeiter Mike McQuaid hat sich des Themas „suboptimale Pull Requests“ angenommen, veranschaulicht ihre verschiedenen Ausprägungsformen und gibt einige praktische Tipps, wie man diese am besten schließt, ohne dabei die Community zu vergraulen.

Typ Nummer 1: Pull Requests, die man nicht akzeptieren will

Manche Pull Request will man einfach nicht akzeptieren, z. B. weil ein bestimmtes Feature den angedachten Rahmen des Projekts sprengen würde. McQuaid empfiehlt in derart gelagerten Fällen, den Pull Request zu schließen und dabei so respektvoll wie möglich zu erläutern, warum dies geschieht. Idealerweise, so McQuaid weiter, beschreibt man im Rahmen einer CONTRIBUTING.md-Datei (Paradebeispiel: Git LFS) detailliert, welche Feature-Requests akzeptabel sind – unnötige Arbeit von Contributern wird so im Vorfeld verhindert.

Typ Nummer 2: Pull Requests, die man nicht akzeptieren kann

In manchen Fällen kann man einen Pull Request schlichtweg nicht akzeptieren, da er beispielsweise den kontinuierlichen Integrationstests zuwiderläuft. Ist der Contributor entweder nicht willens, entsprechend notwendige Änderungen vorzunehmen oder reagiert gar überhaupt nicht, empfiehlt McQuaid, zunächst einige Wochen verstreichen zu lassen. Sollte sich am Status quo auch dann nichts geändert haben, kann man den Request getrost schließen. McQuaids Tipp: Auch dieses Vorgehen in der CONTRIBUTING.md-Datei transparent machen.

Typ Nummer 3: Pull Requests bei unbetreuten Projekten

Hat man kein Interesse mehr daran, ein Projekt weiterzuentwickeln und stellt es quelloffen zur Verfügung, sollte man diesem Umstand in der README Rechnung tragen und klar zum Ausdruck bringen, dass Pull Requests nicht erwünscht sind. Trudeln dennoch welche ein, sollte man sie McQuaid zufolge jedoch nicht wortlos schließen, sondern jeweils eine kurze Rückmeldung geben (Standardantwort genügt). Haben andere Tüftler das Projekt geforkt und so neu belebt, bietet sich natürlich eine entsprechender Verweis (z. B. erneut in der README) an.

Typ Nummer 4: Vom Thema abgekommene Pull Requests

Diskussionen über Pull Request können – wie jede Kommunikation – manchmal völlig vom ursprünglichen Thema abkommen oder gar in handfesten Streitereien ausarten. McQuaid empfiehlt in diesem Fall ein rigoroses Durchgreifen: Den Pull Request schließen und das ursprüngliche Thema in einem neuen Pull Request wiederbeleben.

Aufmacherbild: a woman with a sign in her hands with the words thank you von Shutterstock / Urheberrecht: GongTo

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: