Vorschlag für gemeinsames Review für ein gesünderes Clippy
(blog.rust-lang.org)- Der Rust-Linter Clippy hatte in den vergangenen Monaten einen Review-Engpass bei Pull Requests; deshalb wird ein gemeinsamer Review-Prozess eingeführt, bei dem Beitragende zunächst gegenseitig ihre Änderungen ansehen
- Da es im Clippy-Team keine finanziell unterstützten Clippy-Teammitglieder für Wartungsarbeit gibt, konzentrieren sich Review- und Verwaltungsaufwand auf die Freizeit der Maintainer, wodurch das Burnout-Risiko steigt
- Im neuen Prozess weist @rustbot Beitragende beim Öffnen eines Pull Requests darauf hin, bevorzugt einen anderen Pull Request anzusehen, der noch kein Review hat
- Wer den Pull Request eines anderen Beitragenden reviewed hat, kommt auf eine secret list; anschließend erhält der eigene Pull Request bei den Team-Reviewern Priorität
- Das Clippy-Team hofft, dass der Rust Foundation Maintainers Fund und die Beteiligung der Community helfen, die Maintainer zu entlasten und den Zustand des Projekts zu verbessern
Clippys Review-Engpass
- Clippy ist ein Rust-Linter-Projekt, bei dem viele Beitragende Features und Bugfixes als Pull Requests einreichen
- In den vergangenen Monaten hat fehlende Review-Kapazität zu einem Engpass bei der Bearbeitung von Pull Requests geführt
- Anders als bei einigen anderen Rust-Teams gibt es im Clippy-Team derzeit niemanden, der für Arbeit an Clippy bezahlt wird
- Nicht einmal auf Teilzeitbasis erhält jemand Unterstützung
- Die Wartungslast liegt in der Freizeit der Maintainer
- Diese Struktur kann zu Burnout führen
- Das Team hofft, dass der neu geschaffene Rust Foundation Maintainers Fund dabei hilft, Finanzmittel für Clippy-Maintainer zu sichern
- Wer beitragen möchte, kann an Rust Foundation Sponsors spenden
Ein Prozess, in dem Beitragende sich gegenseitig reviewen
- Ziel des neuen Prozesses ist es, dass Beitragende einander helfen, damit Pull Requests schneller reviewed und gemergt werden
- Wenn ein Beitragender einen Pull Request öffnet, läuft der Prozess so ab, dass zuerst der Pull Request eines anderen Beitragenden angesehen wird
- Jeder Beitragende reviewed mindestens einen Pull Request
- Die Struktur soll verhindern, dass Beiträge anderer lange liegen bleiben
- @rustbot weist Autorinnen und Autoren neuer Pull Requests darauf hin, sich andere Pull Requests anzusehen
- Wenn möglich, haben Pull Requests ohne bisheriges Review Vorrang
- Beitragende, die ein Review abgeschlossen haben, kommen auf eine besondere secret list
- Danach erhält ihr eigener Pull Request bei den Team-Reviewern Priorität
- Dieser Ansatz ist vom Open Code Review-System des Bevy-Projekts inspiriert
- Clippy hat auch früher schon Updates vorgenommen, um den Gesundheitszustand des Projekts zu verbessern
- Der Feature Freeze von 2025 war erfolgreich
- Dabei gewann das Team Wissen, Vertrauen und die Gewissheit, dass sich die Rust-Community für Clippy und die richtige Arbeitsweise interessiert
- Das Clippy-Team ist überzeugt, dass Clippy mit Hilfe der Community stärker und gesünder werden kann
1 Kommentare
Kommentare auf Lobste.rs
Ehrlich gesagt fand ich weniger diese Ankündigung interessant als vielmehr den im Artikel verlinkten öffentlichen Review-Prozess von Bevy. Das war ein Beitrag, der früher schon auch hier gepostet wurde, aber kaum diskutiert wurde, und ich halte ihn für einen wirklich durchdachten und klugen Ansatz.
Ich freue mich, dass er gut funktioniert, und überrascht bin ich nicht. Hoffentlich erzielt Clippy ähnliche Ergebnisse.
Dieses System fördert kleine, schrittweise PRs, weil sie für alle — sogar für Erstbeitragende — deutlich leichter zu reviewen sind. Große PRs brauchten bis zum Merge viel länger, und das halte ich für richtig. Sie sind schwerer zu reviewen und erfordern ein gewisses Verständnis des Codes. In der Regel wurden PRs mit vielen großen Features von Maintainer:innen oder Fachleuten in dem jeweiligen Bereich bis zum Abschluss vorangetrieben.
Wenn dir der Beitrag gefallen hat, könnten dir vom selben Autor auch die Bevy-Maintenance-Beiträge Triage-by-controversy and community review und The Tyranny of Nits gefallen.
Einer der Gründe, warum ich bei Open-Source-Projekten, zu denen ich beitrage, nicht besonders gut bei PR-Reviews helfe, ist, dass ich kaum Expertise habe und mir nicht sicher bin, ob ich dafür qualifiziert bin.
Die Prozesse von Clippy und Bevy geben auch weniger erfahrenen Reviewer:innen eine legitime Möglichkeit, sich einzubringen, und das halte ich für einen ziemlich guten Ansatz.
Nur anhand des Titels hatte ich etwas anderes erwartet.
Es wirkt so, als ließe sich das leicht missbrauchen, indem man ein paar Accounts erstellt und PRs über mehrere Accounts einreicht.
Ich weiß nicht genau, was man dadurch gewinnen würde, aber allein auf eine geheime Liste toller Contributor:innen zu kommen, könnte schon ein Anreiz sein.
Das funktionierte am besten, wenn Contributor:innen am selben Projekt arbeiteten, aber ich habe gesehen, dass es auch bei nicht zusammenhängenden Arbeiten so gemacht wurde. Ich hoffe, dass Clippy eine ähnliche Praxis etabliert. Review-Tauschs sorgen dafür, dass Arbeit schneller gemergt wird, und fördern eine kollaborative Community.
Allerdings könnte der Absatz in diesem Blogbeitrag, der den Review-Mechanismus vorstellt, verbessert werden. Momentan liest er sich wie: „Wenn du kurz über einen anderen PR drüberschaust, mergen wir deinen PR schneller“ — und ich glaube nicht, dass das die beabsichtigte Botschaft ist. Stattdessen sollte der Fokus darauf liegen, mit anderen Collaborators zusammenzuarbeiten. Wenn man Leute ermutigt, in den Zulip-Channel von Clippy zu gehen, einen Review-Tausch vorzuschlagen und gemeinsam am selben Projekt zu arbeiten, kann das eine gesündere Community schaffen, ohne zum Missbrauch des Systems anzuregen.
Beides scheint sich ziemlich leicht vermeiden zu lassen: Review-Paare zufällig zuweisen, damit nicht mehrfach die Arbeit derselben Person reviewt wird, und nur Reviews für PRs zählen, die am Ende tatsächlich gemergt wurden.
Ich betreibe https://www.CodeTriage.com als Service, der dabei hilft, PRs und Issues anderer Leute zu reviewen.