Propuesta de revisión colaborativa para un Clippy más saludable
(blog.rust-lang.org)- El linter de Rust Clippy ha sufrido en los últimos meses un cuello de botella en la revisión de pull requests, por lo que se introdujo un proceso de revisión colaborativa en el que los contribuidores revisan primero los cambios de otros
- No hay miembros del equipo de Clippy financiados para tareas de mantenimiento, así que la carga de revisión y gestión se concentra en el tiempo libre de los maintainers, lo que aumenta el riesgo de burnout
- En el nuevo proceso, cuando un contribuidor abre un pull request, @rustbot le indica que revise primero otro pull request que aún no tenga revisión
- Quien revise el pull request de otro contribuidor entra en una secret list, y luego su propio pull request recibe prioridad por parte de un revisor del equipo
- El equipo de Clippy espera que el Rust Foundation Maintainers Fund y la participación de la comunidad ayuden a reducir la carga de los maintainers y mejorar el estado del proyecto
El cuello de botella de revisiones que enfrenta Clippy
- Clippy es un proyecto de linter para Rust en el que muchos contribuidores envían funciones y correcciones de bugs mediante pull requests
- En los últimos meses, la falta de capacidad de revisión generó un cuello de botella en el procesamiento de pull requests
- A diferencia de algunos otros equipos de Rust, actualmente en el equipo de Clippy no hay nadie que reciba financiamiento por trabajar en Clippy
- Ni siquiera hay personas con apoyo a tiempo parcial
- La carga de mantenimiento recae en el tiempo libre de los maintainers
- Esta estructura puede llevar al burnout
- El equipo espera que el recién creado Rust Foundation Maintainers Fund ayude a conseguir financiamiento para los maintainers de Clippy
- Quienes quieran contribuir pueden donar a Rust Foundation Sponsors
Proceso para que los contribuidores se revisen entre sí
- El objetivo del nuevo proceso es que los contribuidores se ayuden entre sí para que los pull requests sean revisados y fusionados más rápido
- Cuando un contribuidor abre un pull request, el flujo consiste en revisar primero el pull request de otro contribuidor
- Cada contribuidor revisa al menos un pull request
- Es una estructura pensada para que las contribuciones de otras personas no queden abandonadas durante mucho tiempo
- @rustbot le indicará al autor de un nuevo pull request que revise otros pull requests
- Si es posible, se priorizarán los pull requests que aún no tengan revisión
- El contribuidor que complete una revisión entra en una secret list especial
- Luego, su propio pull request recibe prioridad por parte de los revisores del equipo
- Este enfoque se inspira en el sistema Open Code Review del proyecto Bevy
- Clippy ya había realizado antes actualizaciones para mejorar la salud del proyecto
- El Feature Freeze de 2025 fue exitoso
- En ese proceso, el equipo ganó conocimiento, confianza y la certeza de que la comunidad de Rust se interesa por Clippy y por la forma correcta de trabajar
- El equipo de Clippy considera que, con la ayuda de la comunidad, Clippy puede volverse más fuerte y saludable
1 comentarios
Comentarios de Lobste.rs
Sinceramente, más que este anuncio, me pareció más interesante el proceso público de revisión de Bevy que está enlazado en el artículo. Es un texto que ya había aparecido aquí antes, aunque no se discutió mucho, y me parece un enfoque realmente considerado e inteligente.
Me alegra, y no me sorprende, que funcione bien. Ojalá Clippy obtenga resultados parecidos.
Este sistema fomenta PR pequeños e incrementales, porque así cualquiera, incluso alguien que contribuye por primera vez, puede revisarlos mucho más fácilmente. Los PR grandes tardaban mucho más en fusionarse, y creo que así debe ser. Son más difíciles de revisar y requieren cierto nivel de comprensión del código. Por lo general, los PR con muchas funcionalidades grandes los empujaba hasta el final algún mantenedor o experto del área.
Si te gustó ese texto, quizá también te gusten otros del mismo autor sobre mantenimiento de Bevy: Triage-by-controversy and community review y The Tyranny of Nits.
Una de las razones por las que no ayudo mucho con las revisiones de PR en los proyectos open source a los que contribuyo es que tengo muy poca experiencia, así que no estoy seguro de tener la autoridad para hacerlo.
Los procesos de Clippy y Bevy permiten que revisores con menos experiencia participen de forma legítima, y me parece una muy buena forma de hacerlo.
Solo por el título, era algo distinto de lo que esperaba.
Parece fácil abusar de esto creando varias cuentas y enviando PR desde varias de ellas.
No tengo muy claro qué se ganaría con eso, pero aparecer en la lista secreta de colaboradores destacados podría ser un incentivo en sí mismo.
Funcionaba mejor cuando los colaboradores trabajaban en el mismo proyecto, pero también he visto que se haga así con trabajos no relacionados. Ojalá Clippy desarrolle una práctica similar. El intercambio de revisiones ayuda a que el trabajo se fusione más rápido y fomenta una comunidad colaborativa.
Dicho eso, el párrafo de esta entrada de blog que presenta el mecanismo de revisión podría mejorarse. Ahora se lee como “si le echas un vistazo rápido a otro PR, fusionaremos el tuyo más rápido”, y no creo que ese sea el mensaje que se quiere transmitir. En su lugar, debería centrarse en trabajar junto con otro colaborador. Si se invita a la gente a ir al canal de Zulip de Clippy para proponer intercambios de revisión y trabajar juntos en el mismo proyecto, se puede construir una comunidad más saludable sin incentivar el abuso del sistema.
Ambas cosas parecen bastante fáciles de evitar de esta forma: asignar parejas de revisión al azar para que no se revise varias veces el trabajo de la misma persona, y contabilizar solo las revisiones de PR que finalmente se fusionen.
Mantengo https://www.CodeTriage.com como un servicio para ayudar a revisar PR e issues de otras personas.