O que o Rails realmente integra

É sexta-feira à tarde, e uma query devolve linhas que você não pediu. Você abre o código do Active Record no seu bundle, acha o trecho que monta a condição e vê a correção. São quatro linhas.

Escrever essas quatro linhas não é a parte difícil. Fazer com que sejam integradas a um framework do qual inúmeras aplicações dependem é outro trabalho, com regras próprias. Quase ninguém explica essas regras antes de você gastar um fim de semana nelas.

Então aqui estão, antes do fim de semana.

O filtro, dito com clareza

O Rails não trata todas as contribuições do mesmo jeito. Três tipos de mudança entram por três portas bem diferentes:

Essa tabela é toda a estratégia desta lição. Uma correção de documentação é o maior valor que você produz por hora, e ela é bem-vinda. Uma correção de bug com um teste que falha é a contribuição de código mais confiável que existe. Uma funcionalidade é uma aposta arriscada, e o motivo quase não tem a ver com a qualidade do seu código.

Por que funcionalidades são recusadas

Cada método público que o Rails entrega é uma promessa que ele precisa cumprir por anos. Alguém vai chamá-lo em produção, numa aplicação que ninguém do time jamais viu, e uma refatoração futura precisa mantê-lo funcionando. Quem paga esse custo para sempre são pessoas que não o escreveram.

Então o mantenedor não pergunta "isso está correto?" ou "isso está bem escrito?". A pergunta é mais perto disto: toda aplicação Rails precisa disso, ou só uma? Uma funcionalidade que serve lindamente à sua arquitetura e a nenhuma outra pertence a uma gem, e não ao framework. Recusá-la não é um julgamento sobre o código.

É também por isso que uma ideia de funcionalidade aberta como issue, sem código, não vai a lugar nenhum. O guia de contribuição pede que ninguém abra pedidos de funcionalidade no GitHub Issues: uma funcionalidade nova precisa de alguém que escreva o código. Se você quer opinião antes de construir, o guia aponta o fórum de discussão do Rails core. Ter essa conversa antes é o jeito mais barato de não escrever um patch que ninguém queria.

Por que a documentação é subestimada

Os desenvolvedores tratam correções de documentação como o que você contribui quando não é bom o bastante para uma contribuição de verdade. É o contrário. Uma frase errada na documentação da API engana todo mundo que a lê, até alguém corrigir. Quem está mais bem posicionado para perceber é quem acabou de perder uma hora com ela: você, hoje, com a aba do navegador ainda aberta.

Mudanças de documentação também pulam quase todo o atrito. Não há teste que falha para montar nem reprodução para reduzir. E como elas não quebram nada, um pull request só de documentação põe [ci skip] no título, e o build completo não roda para ele.

A parte que fica mesmo que você nunca abra um PR

Há uma habilidade escondida por baixo de tudo isso. Para corrigir algo no Rails você precisa ler o Rails, e o código-fonte completo de cada framework que você usa já está no seu bundle, nesta máquina, agora. Aprender a responder uma pergunta abrindo esse código, em vez de procurar um post de blog, vale mais numa carreira do que a maioria dos patches integrados.

Este curso ensina a contribuir, e ensina esse hábito de leitura como a coisa que você leva de qualquer jeito.

O que este curso cobre

A lição 2 é a reprodução executável: um único arquivo Ruby autossuficiente, que instala as próprias dependências, sobe uma aplicação Rails em miniatura e falha. É a habilidade mais útil aqui, porque um relatório de bug que ninguém consegue rodar é um relatório de bug que ninguém vai corrigir.

A lição 3 põe um checkout do Rails rodando na sua máquina. Ela ensina a rodar os testes de um componente, em vez de todos, e depois a escrever o teste que falha antes de a sua correção existir.

A lição 4 é o próprio pull request: o tamanho do diff, quando uma entrada no CHANGELOG é exigida e como ela é, as convenções de mensagem de commit, rebase e squash, e o que o build confere. Essa lição traz o desafio de código.

A lição 5 é o que acontece depois que você aperta o botão, que ninguém descreve. Ela cobre triagem, silêncio, como insistir sem virar a pessoa que todo mundo silencia e por que um pull request fechado em geral não é sobre você.

A lição 6 cobre backports e branches de release, e por que uma correção integrada hoje pode levar um ano para chegar à sua aplicação.

A lição 7 põe você de volta no seu bundle, lendo o Rails como fonte primária, e fecha o ciclo.

Comece pela reprodução. Todo o resto deste curso depende de o bug poder ser executado.