Como achar um projeto open source para contribuir

O caminho mais curto é um projeto que você já abre todo dia: a biblioteca do seu trabalho, o editor, o aplicativo de linha de comando que você instalou semana passada. A documentação do GitHub sugere exatamente isso: começar por software aberto que você já usa. Você conhece o problema por dentro, e é isso que faz uma issue ou uma correção valer a pena.

Se nada vem à cabeça, o GitHub oferece três portas de entrada: os tópicos (github.com/topics/ seguido de um assunto, como javascript ou python), a lista Trending e a página Explore, que sugere repositórios a partir da sua atividade.

Antes de gastar tempo, confira. A Open Source Guides pede que você veja se o projeto tem licença, commits recentes, mantenedores que respondem e um tom acolhedor. A documentação do GitHub acrescenta que a aba Insights, na visão Pulse, mostra se há atividade. Na prática, são cinco perguntas que cabem em dois minutos:

• Existe um arquivo LICENSE? Sem licença, você não tem permissão clara para contribuir nem para reutilizar o código.
• Houve commits nas últimas semanas?
• As issues e os pull requests recebem resposta, mesmo que seja "não vamos aceitar"?
• Quem mantém escreve de forma educada com quem chega?
• Há README, CONTRIBUTING e CODE_OF_CONDUCT? Eles dizem como o projeto quer receber ajuda.

Muitos projetos marcam issues com rótulos como good first issue e help wanted. A documentação do GitHub cita os dois como forma de achar trabalho. O primeiro costuma indicar uma tarefa pequena e bem explicada; o segundo, que os mantenedores aceitariam ajuda. O significado exato depende do projeto, então leia a descrição da issue e o CONTRIBUTING.

Para a primeira vez, prefira uma tarefa que você consiga terminar em uma tarde: um erro de digitação, um link quebrado, um exemplo que não roda, uma frase confusa na documentação.

A documentação do GitHub lista contribuições que não são código: melhorar a documentação (muitas vezes um bom ponto de partida), testar pull requests de outras pessoas, instalar o projeto e relatar problemas de uso, escrever testes, ajudar com design e dar suporte à comunidade. A Open Source Guides diz o mesmo: código é uma das formas, não a única.

Comente na issue que você vai trabalhar nela. A Open Source Guides recomenda comentar antes de assumir uma issue aberta e conferir se ela ainda faz sentido. Para uma funcionalidade nova ou um defeito que exige decisão de projeto, a documentação do GitHub manda abrir uma issue descrevendo sua abordagem antes de investir muito tempo. Assim você descobre cedo se a ideia cabe no projeto.

Quando tiver escolhido, siga para o passo a passo da primeira contribuição e, se precisar, para o guia de como fazer o fork.

Uma lista fixa de issues envelhece em dias, porque tarefas são fechadas o tempo todo. Por isso, em vez de copiar issues para cá, estas buscas do próprio GitHub mostram as abertas agora. Troque a linguagem no endereço pela que você usa:

• Issues abertas com good first issue em Python
• Issues abertas com good first issue em JavaScript
• Issues abertas com help wanted em TypeScript
• Repositórios com o tópico good-first-issue

Para ler projetos antes de escolher, aqui vão três que existem no GitHub. A lista é um ponto de partida, não uma recomendação: não conferimos a atividade deles hoje, então aplique os cinco sinais acima antes de comentar numa issue.

Quer ensaiar os comandos antes? Use o terminal de faz de conta.

Imagine que você usa três ferramentas e quer ajudar uma delas. Os dados abaixo são inventados, só para mostrar o raciocínio.

O projeto B parece abandonado e o C não tem licença, o que impede você de saber sob quais termos a sua contribuição seria usada. O projeto A passa nos cinco sinais e tem tarefas para iniciantes: é o escolhido. Você abre a lista de issues com o rótulo good first issue, lê o CONTRIBUTING.md inteiro e comenta em uma delas dizendo que quer fazê-la.