Proposition de revue collective pour un Clippy en meilleure santé

 (blog.rust-lang.org)
1 points par GN⁺ 8 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le linter Rust Clippy connaît depuis quelques mois un goulot d’étranglement dans la revue des pull requests ; une procédure de revue collective est donc mise en place pour que les contributeurs examinent d’abord les changements des autres
  • Aucun membre de l’équipe Clippy financé ne travaille sur la maintenance, si bien que la charge de revue et de gestion repose sur le temps libre des mainteneurs, avec un risque accru de burn-out
  • Dans la nouvelle procédure, lorsqu’un contributeur ouvre une pull request, @rustbot l’invite à examiner en priorité une autre pull request qui n’a pas encore reçu de revue
  • Les personnes qui relisent la pull request d’un autre contributeur sont ajoutées à une secret list ; leur propre pull request est ensuite traitée en priorité par un relecteur de l’équipe
  • L’équipe Clippy espère que le Rust Foundation Maintainers Fund et la participation de la communauté contribueront à réduire la charge des mainteneurs et à améliorer l’état du projet

Le goulot d’étranglement des revues chez Clippy

  • Clippy est un projet de linter Rust auquel de nombreux contributeurs soumettent des fonctionnalités et des corrections de bugs via des pull requests
  • Ces derniers mois, le manque de capacité de revue a créé un goulot d’étranglement dans le traitement des pull requests
  • Contrairement à certaines autres équipes Rust, l’équipe Clippy ne compte actuellement personne rémunéré pour travailler sur Clippy
    • Personne n’est financé, même à temps partiel
    • La charge de maintenance repose sur le temps libre des mainteneurs
    • Cette organisation peut mener au burn-out
  • L’équipe espère que le nouveau Rust Foundation Maintainers Fund aidera à obtenir des financements pour les mainteneurs de Clippy

Une procédure où les contributeurs se relisent mutuellement

  • L’objectif de la nouvelle procédure est d’amener les contributeurs à s’entraider afin que les pull requests soient relues et fusionnées plus rapidement
  • Lorsqu’un contributeur ouvre une pull request, le processus l’oriente d’abord vers l’examen de la pull request d’un autre contributeur
    • Chaque contributeur relit au moins une pull request
    • Cette organisation vise à éviter que les contributions des autres restent trop longtemps sans attention
  • @rustbot invite l’auteur d’une nouvelle pull request à examiner une autre pull request
    • Si possible, la priorité est donnée aux pull requests qui n’ont pas encore reçu de revue
  • Le contributeur qui a terminé une revue est ajouté à une secret list spéciale
    • Sa propre pull request reçoit ensuite une priorité auprès d’un relecteur de l’équipe
  • Cette approche s’inspire du système Open Code Review du projet Bevy
  • Clippy a déjà mené par le passé des mises à jour visant à améliorer la santé du projet
    • Le Feature Freeze de 2025 a été un succès
    • Au cours de ce processus, l’équipe a acquis des connaissances, de la confiance, et la conviction que la communauté Rust s’intéresse à Clippy ainsi qu’aux bonnes façons de travailler dessus
  • L’équipe Clippy estime qu’avec l’aide de la communauté, Clippy peut devenir plus solide et plus sain

À lire aussi

1 commentaires

 
GN⁺ 8 시간 전
Avis sur Lobste.rs

  • Honnêtement, plus que cette annonce, c’est le processus de revue publique de Bevy lié dans l’article qui m’a intéressé. C’est un article qui avait déjà été partagé ici aussi sans vraiment susciter de discussion, et je trouve que c’est une approche vraiment réfléchie et intelligente
    Je suis content que ça fonctionne, et ça ne m’étonne pas. J’espère que Clippy obtiendra des résultats similaires

    • C’est moi qui avais posté cet article. J’ai contribué assez activement au moteur de jeu Bevy par le passé, et j’aimais beaucoup leur processus de revue
      Ce système encourage les PR petites et progressives, car elles sont beaucoup plus faciles à relire pour tout le monde, y compris les primo-contributeurs. Les grosses PR prenaient beaucoup plus de temps avant d’être fusionnées, et je pense que c’était la bonne approche. Elles sont plus difficiles à relire et demandent un certain niveau de compréhension du code. En général, les PR avec de grosses fonctionnalités étaient poussées jusqu’au bout par un mainteneur ou un expert du domaine
      Si cet article vous a plu, vous aimerez peut-être aussi les billets du même auteur sur la maintenance de Bevy : Triage-by-controversy and community review et The Tyranny of Nits
    • Je n’ai jamais contribué à Bevy, mais leur structure en groupes de travail semble avoir donné de bons résultats depuis sa mise en place

  • L’une des raisons pour lesquelles je n’aide pas davantage à relire les PR sur le projet open source auquel je contribue, c’est que j’ai très peu d’expertise et que je ne suis pas sûr d’être légitime pour le faire
    Les processus de Clippy et Bevy permettent à des relecteurs moins expérimentés de participer de façon légitime, et je trouve que c’est une très bonne approche

  • En voyant juste le titre, ce n’était pas tout à fait ce à quoi je m’attendais

  • On dirait que ce serait facile à détourner en créant plusieurs comptes et en soumettant des PR avec chacun d’eux
    Je ne vois pas trop ce qu’on y gagnerait, mais le simple fait d’entrer dans une liste secrète de contributeurs cool peut être une incitation

    • Dans le processus de revue de Bevy qui a inspiré cette idée, les échanges de revue sont très fréquents. Moi et un autre contributeur relisons mutuellement nos pull requests, et au final les deux sont fusionnées plus vite
      Ça fonctionnait le mieux quand les contributeurs travaillaient sur le même projet, mais j’ai aussi vu des gens faire ça sur des sujets sans lien. J’aimerais que Clippy développe des pratiques similaires. Les échanges de revue permettent de faire fusionner le travail plus vite et de construire une communauté collaborative
      Cela dit, le paragraphe de ce billet qui présente le mécanisme de revue pourrait être amélioré. Tel quel, on a l’impression qu’il dit : « survole rapidement la PR de quelqu’un d’autre et on fusionnera la tienne plus vite », alors que ce n’est probablement pas le message voulu. Il faudrait plutôt mettre l’accent sur le fait de travailler avec d’autres collaborateurs. Si on encourage les gens à aller sur le canal Zulip de Clippy pour proposer des échanges de revue et à travailler ensemble sur le même projet, on peut bâtir une communauté plus saine sans encourager les abus du système
    • J’ai eu une réaction similaire. Un participant malhonnête pourrait créer de fausses fonctionnalités avec des comptes secondaires et attirer la vraie attention des mainteneurs sur le vrai travail de son compte principal
      Ces deux problèmes semblent assez faciles à éviter de la manière suivante : attribuer les binômes de revue au hasard pour éviter de relire plusieurs fois le travail de la même personne, et ne comptabiliser que les revues sur des PR finalement fusionnées

  • J’exploite https://www.CodeTriage.com , un service pour aider à relire les PR et les issues des autres