Como ser um desenvolvedor descolado
Parte I
Atenção: Esse é o guia mais sem noção do desenvolvimento voltado para open source. Leia com cuidado, pois é muita bobagem para um dia só.
O que é um desenvolvedor descolado?
Para responder a essa pergunta, precisamos voltar ao básico. Entenda que atualmente existem 4 classificações para qualquer tipo de desenvolvedor:
As lendas, os melhores exemplos: Martin Fowler, Robert Cecil Martin (ou tio Bob), Jon "maddog" Hall e outros (não dá para colocar todos que admiro aqui). O caras fazem parte da história. Suas contribuições e suas convicções vão durar para sempre.
Os descolados, os melhores exemplos: John Resig, Rob Pike, TJ Holowaychuk, Paul Irish e outros. Eles criaram e escreveram coisas extraordinárias e continuam muito ativos.
Os descoladinhos, os melhores exemplos: eu e você. Afinal estamos buscando a cada dia ser melhores desenvolvedores e amamos o open source (creio eu que essa é causa de você estar lendo tamanha baboseira até agora). Logo todo bom desenvolvedor que curte código aberto e ajudar a comunidade pode ser considerado um dev em transição.
Os não descolados, os melhores exemplos: talvez seu chefe. Já que é bem provável que ele não dê a mínima para essas coisas de código aberto.
Acho que agora você já consegue entender melhor os conceitos. Então vamos prosseguir!
Eu consigo ser um desenvolvedor descolado?
É claro que consegue, com força de vontade e dedicação você consegue liberar o dev star que existe dentro de você.
Como? Atuando e somando com bastante intensidade.
Exemplos práticos? Dê asas a alguma ideia sua que vá ajudar outras pessoas, contribua em projetos alheios, escreva artigos, compartilhe o seu conhecimento.
Sim, pelo menos todo bom cool dev que se preze já fez algum desses itens acima.
Mas como eu começo a contribuir?
Não quero ficar definindo o que você vai usar. Porém esse guia é baseado nas opções mais populares. Focando e seguindo o uso de git + github. Se você não quer usar nem git, nem github. Aí complica a minha vida.
É essencial para continuar lendo o artigo conhecer essas ferramentas. Recomendo dar uma boa estudada em git e criar uma conta no github para poder brincar com alguma coisa.
Entenda que todo projeto existente tem algo para ser melhorado ou acrescentado, ou mesmo os 2. Seu dever como contribuidor é encontrar esses pontos e correr atrás para poder ajudar.
Uma das melhores coisas de usar o github é que você pode criar um Roadmap para o projeto e trackear/definir pontos críticos para a próxima release pelo uso de issues ou dentro do docs. Uma issue pode apenas ser uma questão sobre o projeto, como também pode ser algum problema encontrado, bug ou até mesmo uma crítica de como funciona o projeto.
Exemplo: O joãozinho, decidiu que quer ser um cool dev. Então ele quer começar a contribuir e ajudar em tudo que puder. Começou a olhar alguns projetos para contribuir, filtrando sempre sua busca por projetos onde ele se sente confortável com a tecnologia usada. Por fim, chegou a conclusão de ajudar em um projeto do jQuery, o globalize. Para quem não conhece o Globalize, é uma biblioteca para internacionalizar dados.
O problema é o seguinte, se Joãozinho apenas der um fork no projeto ele vai ficar extremamente perdido no que ele vai poder ajudar. Logo para descobrir/entender o que ele pode fazer para contribuir com o projeto, ele pode fazer 2 coisas:
Olhar as issues e sair caçando algum problema/melhoria em que possa atuar OU entrar em contato com os mantenedores do projeto e então pedir para explicar o projeto e qual o futuro dele. Normalmente é super tranquilo entrar em contato e é até melhor pois você acaba sabendo de coisas que muita das vezes não estão definidas nas issues ou no Roadmap (se existir uma boa documentação).
Após Joãozinho identificar algo em que ele possa ajudar no projeto. Aí vai depender de projeto para projeto, normalmente nos docs ou no arquivo do readme.md ou contributting.md fica especificado como você vai trabalhar em cima daquela funcionalidade ou conserto que você está implementando, seja feature, hotfix ou qualquer coisa.
Mas vamos supor que o projeto segue como arquitetura o gitflow, então você pode apenas dar um fork no projeto, criar uma branch dentro do seu remote com o prefixo da implementação seguido da funcionalidade que você vai aplicar.
Um exemplo; Se você vai criar o método de formatação de moedas para o globalize.
git checkout -b feature/currency-formatter
Ah! uma dica, antes de sair escrevendo código igual um louco, crie uma issue ou até mesmo no próprio PR, mostre e descreva a implementação da funcionalidade que você vai desenvolver (sério, isso vai te poupar muito tempo).
Se os mantenedores chegarem num senso sobre seu PR (e vai por mim, isso as vezes pode levar dias), provavelmente vai ter sinal verde para terminar a implementação.
Mas é claro que você também pode implementar/desenvolver tudo de uma vez e depois mandar o PR. Nesse caso é super normal ser solicitado alguns ajustes sobre o que foi desenvolvido.
Mas isso tudo varia de contribuidor para contribuidor. Eu pessoalmente prefiro a primeira opção porque normalmente me poupa tempo.
Essas dicas eu aprendi tendo muitos dos meus Pull Requests como closed. Normalmente eu acabava criando algo que não tinha tanto sentido para implementar, algo desnecessário para o projeto. Enquanto haviam muitos outros problemas de verdade que eu poderia estar resolvendo.
Comecei então a conversar com os mantenedores dos projetos e por fim mudando a minha forma de trabalhar com projetos abertos.
Recomendo a você seriamente ver esse vídeo:
Neste vídeo você vai ver gente fera que já contribuiu no core do jQuery e hoje tem projetos bastantes conhecidos. Um deles é o Rick Waldron, criador do johnny-five (Te permite usar JavaScript e aplicar os seus conhecimentos de web para controlar arduino). E o mais legal é ver que, até mesmo esses caras, começaram errando muito e tendo muitas colaborações rejeitadas. Ao mesmo tempo mostra como eles conseguiram mudar isso. Adicional: o relato mais legal no vídeo na minha opinião, é a história do Mike Sherov.
Mas a verdade é que todos eles tiveram vontade de contribuir em algo e não tiveram medo de errar. Isso é ser descolado.
A parte II desse artigo sai semana que vem, se ninguém me condenar pelas besteiras que falei na introdução deste artigo. Pretendo falar sobre a formatação e semântica de código ideal para ser aceito em projetos abertos.
Até a segunda parte então!
