Pachi 🥑 Como Developer Advocate para o GitHub, com frequência me perguntam como começar um projeto Open Source, e meu conselho aqui é simples, criei uma organização dentro do GitHub (leia mais sobre isso aqui) e comece a documentar seu projeto.
Mas começar um projeto, em tese, é fácil. A parte difícil é manter essas contribuições, e manter a comunidade ao redor desse projeto saudável e sustentável.
Então hoje vou compartilhar algumas dicas para que seu projeto Open Source atraia pessoas que queiram contribuir e seja capaz de manter essas pessoas engajadas e ativas.
Tenha um README bem escrito
Uma das maiores barreiras que encontramos quando queremos contribuir com Open Source é simplesmente não compreendermos o projeto. Por isso é essencial que o arquivo README.md, que é a página inicial do seu projeto, seja algo organizado e informativo.
Você pode aprender mais sobre como escrever um bom README aqui.
Tenha um Guia de Contribuições
Outro arquivo importante é o guia de contribuições. Nesse documento, você vai explicar como a comunidade pode contribuir para seu projeto. Você pode abordar os tipos de contribuição que seu projeto aceita, como fazer essas mudanças e outras informações que você ache necessário que uma pessoa saiba antes de contribuir.
Você pode acessar o exemplo da imagem abaixo, nesse link.
Não esqueça o Código de Conduta
O Código de Conduta é um documento que dita as regras e comportamentos esperados das pessoas que contribuem para o projeto, garantindo respeito e outros valores que você julgue necessário.
É importante que esse código também informe as consequências caso alguém descubra as regras.
Um ótimo exemplo é o Código de Conduta da Feministech, uma comunidade feminista de pessoas trans, não-binárias e mulheres cis que produzem, consomem e compartilham conteúdo sobre tecnologia.
Nele você encontra informações sobre a comunidade, sua missão e valores, o que é esperado de quem entra na comunidade, o que faz uma pessoa sair dessa comunidade e as consequências de ignorar as regras.
Lá eu também encontrei referência a outros códigos de conduta, e vou deixar os links aqui para você usar como base:
Good First Issues (Boas issues para iniciantes)
Ter issues no seu repositório é uma maneira de deixar nítido que seu projeto aceita ajuda, e quanto melhor documentada e detalhada for essa issue, melhor.
Outro ponto importante a se considerar é que existem muitas pessoas que querem contribuir com código aberto, mas não têm ideia de como começar, e é aí que entra a tag good-first-issue que significa boa primeira issue.
Você pode usar essa tag em issues que você tem um nível de dificuldade que uma pessoa iniciante consiga fazer. E mais uma vez eu repito a importância de documentar bem as suas issues, assim a pessoa iniciante que encontrar sua good-first-issue vai conseguir trabalhar com mais facilidade.
Invista em mentorar
Se você está na área de TI, provavelmente percebeu que existem MUITAS pessoas iniciantes procurando pela primeira oportunidade. Para essas pessoas que estão iniciando, contribuir com código aberto é ainda mais intimidador.
Então, você pode dar um passo além de ter uma good-first-issue bem documentadas você pode oferecer uma mão para essas pessoas iniciantes que querem contribuir. Não precisa ser muito, talvez oferecer uma mentoria de meia hora para explicar melhor a issue e tirar dúvidas, uma sessão de pair programming, ou às vezes apenas comentar na issue que você está disponível para tirar qualquer dúvida dessa pessoa.
O GitHub Brasil tem uma canal na Twitch, onde faço lives semanais, e recentemente em um stream chamado Open Source Brasil, quadro onde eu bato um papo com pessoas brasileiras que mantêm projetos de código aberto, a convidada Melissa Mendonça mencionou uma iniciativa que eu achei super legal: Nos projetos em que ela trabalha, existe a tag sprintable que é ainda mais legal do que a good first issue, essas issues são esperadas de ser terminadas em um Sprint, e pessoas que queiram resolver essas issues trabalham com pessoas mais seniores que as dão mentoria para resolver a issue.
Sprintable quer dizer nesse sentido. algum mini-projeto que provavelmente poderia ser desenvolvido numa sprint, com um mentor respondendo suas perguntas.
Em resumo
As regras que eu trouxe podem parecer simples, mas elas fazem toda a diferença em como pessoas de fora veem o seu projeto.
Podemos resumir isso tudo em: seja gentil e tenha uma boa documentação que além de detalhada, seja escrita pensando em pessoas que não conhecem seu projeto e/ou são novas em tecnologia.
Então se você mantém um projeto, não se esqueça:
Renha um README bem escrito
Tenha um Guia de Contribuições
Não esqueça o Código de Conduta
Good First Issues (Boas issues para iniciantes)
Invista em mentorar
