Reciprocidade em code review: revisei 47 PRs open-source em 6 meses, meu refactor grande passou em 3 dias

Existe uma crença entre devs de que PR bom passa por qualidade técnica. Código limpo, testes cobertos, descrição clara, e o merge acontece. Trabalhei acreditando nisso durante anos. E olhando para o meu histórico de PRs open-source de 6 meses atrás para cá, essa crença estava contando só metade da história.

A outra metade é reciprocidade. Robert Cialdini nomeou o princípio em 1984 no livro “Influence”: quando alguém faz algo por você, surge uma pressão psicológica de retribuir. É o mesmo mecanismo que faz você aceitar o folder da rua depois que a pessoa te deu um sorriso e um “bom dia, moço”.

O código não é imune. Testei durante 6 meses e o efeito é embaraçosamente forte.

O experimento acidental

Não comecei querendo testar Cialdini. Comecei porque estava usando três projetos open-source ativamente (o SDK do Claude Code, um plugin de Astro, e uma biblioteca de MCP) e percebi que tinha várias issues abertas para os três. Em vez de esperar, comecei a mandar PRs pequenos. Correção de docs, typo em README, um teste faltando, um edge case de handler.

Em 6 meses acumulei 47 PRs merged nesses três projetos. Nada de grande porte, cada um deles um pequeno favor.

O que aconteceu foi o seguinte: em fevereiro deste ano, precisei propor um refactor grande em um desses projetos. Refactor que tocava em 14 arquivos e mudava a assinatura de uma API interna, longe de ser uma correção pequena. Sabia que ia gerar discussão.

Abri o PR. Passou em 3 dias.

Não fui eu que fiz o PR ficar bom. O PR era discutível. O que aconteceu é que os maintainers do projeto tinham a minha cara na memória de 47 revisões cordiais anteriores. Quando meu PR chegou na fila deles, não estava começando do zero. Estava começando de “esse dev já fez umas coisas boas aqui”.

O contraponto que veio depois

Um mês depois, um contribuidor novo do mesmo projeto abriu um PR de escopo parecido. Refactor médio, tocava em 10 arquivos, mudança de assinatura interna.

Levou 3 semanas para ser merged.

Não fui eu quem revisou esse PR, mas acompanhei a discussão. A qualidade técnica era comparável à do meu. O que faltava era o histórico. Cada dúvida que aparecia recebia o benefício da dúvida na direção oposta. “Isso vai quebrar o comportamento X?” perguntado a mim virava “acho que não, você já viu esse caso?”. Perguntado a ele virava “prove que não quebra e me mostra o teste”.

Sacanagem dos maintainers não tem nada a ver, é como o cérebro humano funciona quando precisa avaliar risco com histórico curto.

Por que dev experiente ignora isso

Devs seniores gostam de acreditar que o processo é meritocrático. Código bom passa, código ruim é rejeitado, cada PR é avaliado no seu próprio mérito. É uma narrativa reconfortante.

A narrativa é falsa por um motivo bem prático: quem revisa PR é uma pessoa, não um linter. Pessoa tem carga cognitiva, humor variável, contexto acumulado. Quando o revisor abre o PR pela quinta vez do dia e vê o nome de alguém que já contribuiu 47 vezes sem quebrar nada, o custo de aprovar é menor. Isso é apenas como a confiança funciona no mundo real, e não vale tratar como um enviesamento a corrigir.

Ignorar a reciprocidade não deixa o processo mais justo. Só deixa o seu PR mais lento.

Como aplicar sem virar cínico

Aqui é onde muita gente estraga a estratégia. Se você começa a revisar PRs alheios com o objetivo declarado de “acumular crédito para o próximo pedido meu”, dois problemas aparecem.

Primeiro, o outro percebe. É um ponto que aparece na leitura de Cialdini: reciprocidade que soa calculada tende a ser detectada. A gentileza que o outro sente como cálculo aciona o efeito contrário, quer distância.

Segundo, você acaba deixando reviews ruins. Review feita por obrigação estratégica é review superficial. Você marca “approve” só para gerar volume, e quando o projeto tem um bug depois, sua assinatura está no PR que passou sem análise de verdade.

O que funciona é diferente. Revisar PRs de projetos que você usa de verdade, porque quer que eles sejam melhores, porque tem uma opinião técnica sobre o que está sendo mudado. O acúmulo de crédito é subproduto, não objetivo. É a diferença entre um investidor que faz favor esperando retorno e um investidor que faz o favor porque acha que a empresa vai crescer de qualquer jeito.

O lado defensivo: quando você é o revisor

Vale reconhecer quando estão fazendo isso com você. Se você é maintainer de um projeto ativo, todo mês recebe PRs de gente nova que “está construindo relacionamento”. Alguns são genuínos, outros são preparação para pedir algo grande.

Como diferenciar? A saída barata é olhar para o padrão de longo prazo. Genuíno continua contribuindo com pequenos favores depois que o pedido grande é atendido ou rejeitado. Calculado desaparece.

Quando você notar o padrão do desaparecimento acontecendo repetidamente, ajuste o filtro. Não trate o próximo PR “de acúmulo de crédito” como um vale-brinde. Trate cada PR pelo mérito individual e explicite que o histórico anterior não compra nada além de um pouco mais de paciência ao ler.

A regra que eu adotei

Depois desses 6 meses, formalizei uma regra pessoal.

Antes de abrir um PR grande em qualquer projeto open-source, eu tenho pelo menos 5 PRs pequenos merged no mesmo repositório. Se não tenho, escolho outro projeto ou aceito que o PR grande vai levar semanas de discussão.

A regra existe para reconhecer que estou pedindo tempo do maintainer, e tempo do maintainer é caro. Manipulação nenhuma. Ter contribuído antes é a forma mais barata de mostrar que valoriza o tempo dele o suficiente para investir no projeto sem pedir nada de volta.

Se você abre uma issue de refactor grande em um projeto onde nunca contribuiu, você é um desconhecido pedindo café emprestado. Pode ser um bom pedido. Você pode ter razão. Só que a probabilidade de dar certo é baixa, e não porque o café não valha a pena.

Uma última observação

Os 47 PRs merged em 6 meses parecem muito, mas dá cerca de 2 PRs por semana. É uma revisão a cada 3 dias, no tempo que você gastaria assistindo um YouTube técnico. Se você está usando um projeto open-source ativamente e reclamando de coisas nele, esse já é o custo natural de ter opinião sobre o projeto.

Faça de qualquer jeito. O crédito com o maintainer vem de graça em cima. E daqui a 6 meses, quando você precisar do refactor grande passar em 3 dias, vai lembrar que Cialdini estava certo em 1984 e continua certo agora.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews