Proposta de revisão colaborativa para um Clippy mais saudável
(blog.rust-lang.org)- O linter de Rust Clippy vem enfrentando, nos últimos meses, um gargalo na revisão de pull requests, então foi introduzido um processo de revisão colaborativa em que contribuidores avaliam primeiro as mudanças uns dos outros
- Como não há membros da equipe do Clippy financiados para trabalhar na manutenção, a carga de revisão e gestão se concentra no tempo livre dos mantenedores, aumentando o risco de burnout
- No novo processo, quando um contribuidor abre um pull request, o @rustbot orienta essa pessoa a analisar primeiro outro pull request que ainda não tenha revisão
- Quem revisa o pull request de outro contribuidor entra em uma secret list, e depois seu próprio pull request passa a receber prioridade dos revisores da equipe
- A equipe do Clippy espera que o Rust Foundation Maintainers Fund e a participação da comunidade ajudem a reduzir a carga dos mantenedores e a melhorar a saúde do projeto
O gargalo de revisão enfrentado pelo Clippy
- Clippy é um projeto de linter para Rust no qual muitos contribuidores enviam funcionalidades e correções de bugs por meio de pull requests
- Nos últimos meses, a capacidade de revisão insuficiente criou um gargalo no processamento de pull requests
- Diferentemente de algumas outras equipes do Rust, atualmente não há ninguém na equipe do Clippy recebendo financiamento para trabalhar no Clippy
- Nem mesmo em regime de meio período
- A carga de manutenção fica sobre o tempo livre dos mantenedores
- Essa estrutura pode levar ao burnout
- A equipe espera que o recém-criado Rust Foundation Maintainers Fund ajude a garantir financiamento para os mantenedores do Clippy
- Quem quiser contribuir pode doar para Rust Foundation Sponsors
Processo em que contribuidores revisam uns aos outros
- O objetivo do novo processo é fazer com que contribuidores ajudem uns aos outros para que pull requests sejam revisados e mesclados mais rapidamente
- Quando um contribuidor abre um pull request, o fluxo passa a ser primeiro analisar o pull request de outro contribuidor
- Cada contribuidor revisa pelo menos um pull request
- A estrutura busca evitar que a contribuição de outra pessoa fique parada por muito tempo
- O @rustbot orienta autores de novos pull requests a analisarem outros pull requests
- Sempre que possível, a prioridade são pull requests que ainda não tenham revisão
- O contribuidor que conclui uma revisão entra em uma secret list especial
- Depois disso, seu próprio pull request recebe prioridade dos revisores da equipe
- Essa abordagem foi inspirada no sistema Open Code Review do projeto Bevy
- O Clippy já realizou atualizações antes para melhorar a saúde do projeto
- O Feature Freeze de 2025 foi bem-sucedido
- Nesse processo, a equipe ganhou conhecimento, confiança e a certeza de que a comunidade Rust se importa com o Clippy e com a forma correta de trabalhar
- A equipe do Clippy acredita que, com a ajuda da comunidade, o Clippy pode se tornar mais forte e saudável
1 comentários
Opiniões no Lobste.rs
Sinceramente, mais do que este anúncio, achei mais interessante o processo de revisão aberta do Bevy que foi linkado no texto. É um post que já apareceu aqui antes, mas não gerou muita discussão, e me pareceu uma abordagem realmente cuidadosa e inteligente
Fico feliz em ver que está funcionando, e não me surpreende. Espero que o Clippy consiga resultados parecidos
Esse sistema incentiva PRs pequenos e incrementais, porque qualquer pessoa, até mesmo quem está contribuindo pela primeira vez, consegue revisar com muito mais facilidade. PRs grandes levavam bem mais tempo para serem mesclados, e acho que era o correto. A revisão é mais difícil e exige certo entendimento do código. Em geral, PRs com funcionalidades grandes acabavam sendo levados até o fim por mantenedores ou especialistas daquela área
Se você gostou daquele texto, talvez também goste de Triage-by-controversy and community review e The Tyranny of Nits, outros textos do mesmo autor sobre manutenção no Bevy
Um dos motivos pelos quais eu não ajudo muito com revisão de PRs em projetos open source para os quais contribuo é que quase não tenho especialização e, por isso, não tenho certeza se estou em posição de fazer isso
Os processos do Clippy e do Bevy permitem que revisores menos experientes participem de forma legítima, e acho isso bem interessante
Pelo título, isso foi um pouco diferente do que eu esperava
Parece fácil de abusar disso criando algumas contas e enviando PRs por várias delas
Não sei exatamente o que alguém ganharia com isso, mas entrar numa lista secreta de contribuidores incríveis por si só pode ser um incentivo
Funcionava melhor quando os contribuidores estavam trabalhando no mesmo projeto, mas já vi isso acontecer até em trabalhos sem relação entre si. Espero que o Clippy desenvolva uma prática parecida. A troca de revisões ajuda o trabalho a ser mesclado mais rápido e fortalece uma comunidade colaborativa
Dito isso, o parágrafo deste post do blog que apresenta o mecanismo de revisão pode ser melhorado. Do jeito que está agora, soa como “dê uma passada rápida no PR de outra pessoa e vamos mesclar o seu mais rápido”, mas imagino que essa não seja a mensagem pretendida. Em vez disso, o foco deveria ser trabalhar junto com outros colaboradores. Se as pessoas forem ao canal do Clippy no Zulip para propor troca de revisões e acabarem trabalhando juntas no mesmo projeto, isso pode criar uma comunidade mais saudável sem incentivar abuso do sistema
Parece bem fácil evitar os dois casos da seguinte forma: definir os pares de revisão de forma aleatória para evitar revisar várias vezes o trabalho da mesma pessoa, e contar apenas revisões de PRs que acabarem sendo mesclados
Eu mantenho o https://www.CodeTriage.com, um serviço para ajudar a revisar PRs e issues de outras pessoas