Você passa por um problema, ou tem uma vontade súbita. Então você abre o seu editor e mergulha no código. Em uma situação boa, o patch é simples, portanto você mesmo corrige o erro, envia um pull request, reclina a cadeira e espera – mesmo quando o patch é simples, a experiência diz que normalmente você vai ter que incorporar algum feedback antes que o seu pull request seja incorporado pelo autor.

Então, vez ou outra, você encontra um problema “cabeludo” – do tipo que parecia simples à primeira vista – e perde a melhor parte do seu dia, ou até mesmo mais do que isso, e quanto mais longe você vai, mais comprometido você fica em chegar no fim. Finalmente, você sai vitorioso: com mais de 300 linhas de patch, uma dúzia de arquivos modificados e a sensação de que acabou de fazer um favor para o mundo – hora de enviar o seu pull request!

É aqui que tudo começa a dar errado. Você espera agradecimento pelo seu tempo, trabalho e esforço, mas o mantenedor olha com horror para o patch enquanto tenta enumerar as razões pelas quais não pode aceitá-lo. Em 50% das vezes, ele não sabe nem por onde começar, então ele procura pelos mínimos defeitos – sua contribuição vai para lugar nenhum, e a culpa não é de nenhum dos dois lados.

Não “empurre” um pull request

Contribuições são sempre bem-vindas, mas patches surpresa são quase sempre um fardo. Sim, você está oferecendo a sua ajuda, mas alguém precisará manter o seu código no longo prazo – faça com que eles comprem a ideia primeiro e evite surpresas. Pior ainda, uma mudança localizada referente a um problema específico irá com frequência desconhecer todas as implicações para o projeto: outros casos de uso, planos para as futuras versões ou decisões de arquitetura em geral. Uma boa ideia pode acabar sendo implementada de forma inapropriada para um determinado projeto. Ela pode ser invalidada por um outro esforço do qual você talvez não tenha o menor conhecimento: pode não ser a hora certa, ou uma dúzia de outras razões que podem conspirar contra você.

Aqueles que são responsáveis por manter o código possuem a melhor perspectiva, portanto, entre em contato com eles o quanto antes. Isso não é para dizer que eles sempre têm razão; você talvez tenha que argumentar levando isso em consideração, mas essa é uma discussão que é melhor ter antes do que depois de escrever o seu código. É um dos paradoxos mais frustrantes no mundo open-source: coisa muito comum seus fãs mais engajados cairem numa armadilha, ao perderem noites e fins de semana trabalhando em uma grande contribuição, apenas para ficarem desapontado quando o mantenedor rejeita o trabalho deles logo de cara.

Revisões de código são difíceis: comece cedo

Da próxima vez, antes de se fechar no editor, abra uma discussão, descreva o problema e a solução e se ofereça para fazer o trabalho. Não deve levar mais de um parágrafo para explicar o objetivo – se você precisar de uma redação, já é um sinal de que você deve quebrar o problema em partes, ou que ele talvez não esteja bem delineado. Se o projeto ou a mudança é grande, escolha um revisor específico e trace o projeto. Peça ajuda e opinião logo no começo e, como num passe de mágica, você verá o seu código ser incorporado dentro do cronograma.

Revisões de código são difíceis. Na verdade, acontece que a efetividade de revisões cai dramaticamente depois de 200-400 linhas de código, e a taxa de inspeção sugerida é de no máximo 300-500 linhas por hora. Tenha isto em mente: divida grandes commits em pedaços pequenos e administráveis. Uma regra de ouro é mirar meia hora de revisão, ou menos de 200 linhas de um código bom e limpo (não necessariamente inteligente). Se houver múltiplos commits, então apresente um plano de desenvolvimento e consiga um feedback para cada parte assim que estiverem prontos.

Um bom trabalho é “entregue” não “empurrado”

Não há nada mais frustrante do que se identificar com este texto, ou ainda pior, estar na reta final de uma experiência desse tipo que não deu certo. Quem contribuiu fica ofendido por não ser reconhecido, e o mantenedor é pego em um dilema: ele quer construir uma comunidade, mas precisa ir contra seus maiores fãs. Não há vencedores aqui, e nenhum dos lados deve ser culpado.

Da próxima vez, antes de se fechar no editor, abra uma discussão, descreva o problema e a solução e se ofereça para fazer o trabalho. Não “empurre” o pull request e também não trabalhe no escuro.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.igvita.com/2011/12/19/dont-push-your-pull-requests/