Como contribuir com open source além do código

Ano passado escrevi um artigo sobre como contribuir para o código aberto. Confesso que quando escrevi o artigo estava focado naquilo que mais gosto de fazer que é codar, porém essa não é a única maneira de contribuir. Quando falamos de open source temos um leque muito grande de formas para contribuir que vão além do código, sendo que essas outras formas são acompanhadas dos mesmos benefícios.

Contribuir com a documentação

Quando falamos de contribuir com a documentação temos duas vertentes:

A primeira é fazer a tradução da documentação, sendo que essa tradução pode ser para sua língua nativa ou uma língua que você esteja aprendendo e deseja praticar. Essa é uma ótima maneira de aprender sobre um projeto, pois você passa a estar por dentro da doc. Também é uma oportunidade de aprimorar um idioma.

A segunda é contribuir para deixar a própria documentação mais rica. Desta forma se há alguma deficiência ou ponto de melhoria, podemos sugerir a alteração para que a documentação seja facilitada para aqueles que vierem a ler depois.

Recentemente eu fiz essa contribuição para melhorar a doc da gem do twitter. Eu estava utilizando a gem em um projeto e precisava retornar uma lista de tweets sem truncar o tweet.

Não encontrei nada na documentação da gem, achei estranho e fui olhar na API do twitter e lá encontrei o parâmetro que deveria passar para a API não truncar os valores. Olhando para o método ele parecia já enviar a informação que eu precisava, o que fiz foi testar. O teste funcionou, então a única coisa que faltava era estar essa informação na documentação para facilitar a vida de quem viesse a precisar daquele parâmetro. Então abri o PR (pull request) para essa melhoria na documentação.

Reportar bugs e melhorias

Antes de contribuir a primeira vez com código eu passei por essa forma de contribuição. Estava utilizando um framework e não encontrei a maneira que eu achava adequada para implementar o Sentry (ferramenta de monitoramento de erros). O framework tinha uma função de tratamento de erros, porém não tinha a opção de logar os erros em uma ferramenta externa. A primeira coisa que fiz foi reportar essa melhoria, pois olhei o código do framework e vi que era possível implementar de forma fácil. Após reportar essa melhoria através de uma issue no github, desenvolvi o código para já aplicar a solução que eu tinha sugerido. Ela foi aceita e hoje faz parte do framework, porém caso eu não tivesse como fazer o código para essa melhoria, ela ficaria sugerida e em algum momento alguém poderia fazer.

O mesmo acontece para bugs, muitas vezes você pode encontrar bugs em projetos open source. É muito importante que você reporte esses bugs. Isso é fundamental para a melhoria do projeto. Nesse cenário é importante ficar atendo, pois quase sempre é necessário passar mais informações para que o cenário do bug possa ser entendido, reproduzido e corrigido.

Revisar código

Uma outra maneira de contribuir é revisando código, muitas vezes codar demanda muito tempo. A revisão acaba sendo uma maneira mais rápida de contribuir sem se afastar do código, porém sem precisar colocar a mão diretamente no mesmo. No meu ponto de vista para fazer esse cara é interessante que você entenda o funcionamento do projeto que pretende vai revisar, pois avaliar um código sem nenhum contexto pode não ser tão eficaz. Um ponto bacana da revisão é que é um dos momentos em que há mais troca de informações entre os devs. Assim você pode expor pontos de vista e ver pontos de vista, saindo dali com uma visão totalmente nova.

 

Se tiver mais interesse sobre o mundo open source darei uma talk no dia 13/06/2019 no TDC BH sobre open source, se dúvidas e sugestões e não quer esperar até lá escreva nos comentários =)