O hack de solicitação pull · Felix Geisendörfer
Publicado:
Depois de escrever sobre código aberto e responsabilidade, gostaria de compartilhar um pequeno hack de colaboração que criei no ano passado. Aqui está:
Sempre que alguém lhe enviar uma solicitação pull, conceda a ele acesso de commit ao seu projeto.
Embora possa parecer incrivelmente estúpido a princípio, usar essa estratégia permitirá que você libere o verdadeiro poder do Github. Deixe-me explicar. No ano passado, percebi que não conseguiria mais alocar tempo suficiente para meus projetos de código aberto. E não estou nem falando sobre consertar bugs ou adicionar recursos, estou falando sobre o acúmulo de pull requests.
Então, por que eu simplesmente não os fundiria? Bem, muitos deles não eram bons o suficiente. Faltavam testes ou documentação, violavam os padrões de codificação ou introduziam novos problemas que o colaborador não havia considerado. Muitas vezes eu explicava os problemas detalhadamente, apenas para descobrir que o colaborador não tinha tempo para fazer as alterações. É claro que eu mesmo poderia fazer esses ajustes, mas isso geralmente levaria tanto tempo quanto se eu mesmo tivesse feito o patch. Então, depois de ver esse padrão acontecer muitas vezes, comecei a negligenciar a maioria das solicitações pull recebidas que não podiam ser mescladas imediatamente.
E então me deparei com o hack que mencionei acima. Eu gostaria de receber o crédito por projetá-lo, mas realmente aconteceu por coincidência. Alguém enviou uma solicitação pull para um projeto que eu não estava mais usando e percebi um problema imediatamente. Porém, como eu não me importava mais com o projeto, e a pessoa que enviou o pull request sim, simplesmente o adicionei como colaborador e disse algo assim: “Não tenho mais tempo para manter este projeto, então dei a você acesso de commit para fazer as alterações que desejar. Seria bom seguir o estilo usado pelo resto do código e adicionar alguns testes a este patch.”
O resultado foi pura magia. Em poucas horas, a mesma pessoa que acabara de enviar um patch bastante medíocre já havia consertado as coisas e feito o commit. Isso era altamente incomum, então comecei a usar a mesma estratégia para alguns outros projetos pequenos que não estava mais interessado em manter. E funcionou, uma e outra vez. É claro que às vezes isso não faria diferença, mas estava claramente funcionando muito melhor do que a minha abordagem anterior.
Dado o sucesso de meus projetos menores, finalmente decidi experimentá-lo também em meus dois projetos mais populares, node-mysql e node-formidable. Inicialmente fiquei muito preocupado em abrir mão do controle desses projetos, mas os resultados falam por si. Ambos os projetos agora são mantidos por um grupo de desenvolvedores incríveis, escrevendo códigos muito melhores do que jamais recebi na forma de solicitações pull antes.
Então, por que isso funciona? Bem, tenho algumas ideias. Depois que as pessoas tiverem acesso de commit, elas não ficarão mais preocupadas com a possibilidade de seu patch não ser mesclado. Eles agora têm o poder de cometê-lo sozinhos, fazendo com que dediquem muito mais trabalho a isso. Fazer o commit/push real também muda seu senso de propriedade. Em vez de entregar uma diferença a outra pessoa, eles agora fazem parte do projeto, possuindo uma pequena parte dele.
Mas a magia não para por aqui. Além do aumento da qualidade de suas contribuições, observei muitas pessoas continuando a ajudar com problemas e patches enviados por outros usuários. É claro que isso é alimentado pelo Github notificando todos os contribuidores em um repositório sobre todas as atividades nele.
Então, você realmente deveria fazer isso para todas as solicitações pull? Provavelmente não. Embora eu tenha dado acesso a vários projetos meus a uma grande quantidade de usuários, ainda estou procurando:
- Perfil do Github: Este usuário pode perder reputação fazendo algo estúpido?
- Habilidade: Com base no patch, acho que o usuário poderia ser um bom desenvolvedor?
- Utilidade: Este patch está resolvendo um problema válido?
Com estas verificações em vigor, penso que esta abordagem é uma forma fantástica de evitar que os projectos fiquem obsoletos, bem como de transformar projectos individuais em pequenas comunidades. No entanto, você está obviamente livre para executar seus projetos da maneira que desejar.
Por último, mas não menos importante, gostaria de agradecer a algumas das grandes pessoas que fizeram contribuições significativas para alguns dos meus projetos recentemente:
Vocês são absolutamente incríveis e não posso agradecer o suficiente por toda a ajuda.
Atualizar: Olhando para trás, conversando com Peter Hintjens no MixIT foi definitivamente uma inspiração para isso.
Atualização 2: Há uma discussão interessante sobre isso no Hacker News agora, parece que outros também usaram essa estratégia com sucesso!
Atualização 3: Há ainda mais discussões acontecendo no Reddit.
— Felix Geisendörfer
Assine este blog via RSS ou e-mail ou receba pequenas atualizações minhas via Twitter.
