Idee

Das Review einer Pull Request wird zum Governance-Mechanismus, sobald Nicht-Entwickler beitragen

Info

Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.

Hauptgedanke

Wenn ein Product Manager eine Pull Request für das Hauptprodukt aufmacht, ist das Review keine technische Kontrolle unter Fachkollegen mehr. Es wird zu dem Ort, an dem die Organisation sagt, was sie anzunehmen bereit ist, von wem und in welchem Zuständigkeitsbereich: Der Beitrag wird gegengelesen, angenommen, korrigiert oder abgelehnt, und dieses Votum ist die einzige reale Grenze, die der Ausweitung der Rollen gesetzt wird.

Die Ablehnung trägt dann eine Information mit drei Lesarten, und nichts in der Pull Request selbst sagt, welche die richtige ist. Vielleicht hat die Person für diese Art von Beitrag noch nicht das Niveau. Vielleicht ist das Thema zu riskant, um es zu öffnen. Oder das Technikteam hat noch nicht die Richtlinien, Werkzeuge und Leitplanken geschaffen, die anderen Profilen einen sicheren Beitrag erlauben würden – und gerade diese dritte Lesart vergisst man, weil sie diejenigen in Frage stellt, die ablehnen.

Eine wiederholte Ablehnung ist also als Signal über die Organisation zu lesen, nicht nur als Urteil über einen Beitrag.

Warum das wichtig ist

Das verlagert eine Grundsatzdiskussion – „Darf ein PM in die Produktion deployen?“ – auf eine bestehende Einrichtung, die bereits mit Werkzeugen versehen und nachvollziehbar ist und Fall für Fall entscheidet, ohne dass eine allgemeine Regel geschrieben werden müsste.

Und es gibt einem Team, das den Beitrag öffnen will, einen beobachtbaren Indikator: Quote und Gründe der Ablehnungen zeigen, wo die Öffnung wirklich steht, unabhängig von den angekündigten Absichten.

Nuancen und Grenzen

Ein impliziter Governance-Mechanismus bleibt ein Mechanismus ohne Mandat: Die Reviewer wägen Fragen von Zuständigkeitsbereich und Risiko ab, ohne dass man sie darum gebeten hätte, und ohne dass ihre Entscheidung anderswo zur Diskussion gestellt werden könnte.

Und das Review sieht nur, was ihm vorgelegt wird. Was außerhalb des Repositorys gebaut wurde – ein internes Werkzeug, eine Automatisierung, ein Dashboard –, entzieht sich dieser Kontrolle vollständig.

Offene Fragen

  • Wo diskutiert man eine Ablehnung, wenn das Review der einzige Ort ist, an dem die Entscheidung gefallen ist, und es kein Ort für Organisationsdebatten ist?