Contribuições não relacionadas a código para o open source

Contribuições sem código são o segredo do sucesso do open source

• Sarah Rainsberger, professora de matemática, não pretendia se tornar voluntariamente uma colaboradora de open source, mas começou a aprender JavaScript e desenvolvimento web ao reconstruir o site do seu coral.
• Ao usar o framework frontend Astro, ela acabou contribuindo com um pequeno trecho de código, um arquivo de configuração, para o projeto e, ao participar da comunidade, passou a apoiar novos usuários do Astro.
• Rainsberger hoje faz parte do grupo principal de mantenedores do Astro, mas não se envolve muito com a base de código e se dedica principalmente à documentação, ajudando outras pessoas a aprender Astro.

Trabalhos sem código importantes em projetos open source

• Projetos open source precisam, além da escrita de código, de documentação, localização, marketing, design gráfico, testes, gestão de comunidade e gestão de releases.
• A importância das contribuições sem código é enorme, e quanto mais complexo o projeto, mais documentação, tutoriais e suporte ele precisa para tornar o código útil.
• Design gráfico, branding e outreach funcionam como sinais da saúde e da seriedade do projeto, permitindo que outros projetos ou empresas o utilizem como dependência.

Por que começar com contribuições sem código

• Contribuições sem código oferecem a pessoas interessadas em funções que não envolvem programação, como comunicação técnica, design gráfico e design de experiência do usuário, uma oportunidade de construir portfólio.
• Programadores também se beneficiam ao aprimorar habilidades de escrita e comunicação, o que pode ajudar na transição para funções como relações com desenvolvedores ou gestão de produto.
• Projetos open source oferecem oportunidades de participação para pessoas de todos os níveis de habilidade, e sem uma compreensão profunda do projeto é difícil fazer contribuições de código realmente significativas.

Como encontrar colaboradores sem código e expressar agradecimento

• Para mantenedores, a melhor forma de encontrar colaboradores é pedir tarefas específicas; também ajuda construir uma comunidade e abrir issues marcadas como "pedido de ajuda" e "boa primeira issue".
• Mentoria é uma das melhores formas de levar colaboradores ao sucesso, e valorizar e reconhecer colaboradores sem código ajuda a motivar os atuais e atrair novos.

Opinião do GN⁺

• É importante reconhecer que o sucesso de um projeto open source exige diversas contribuições que vão muito além de simplesmente escrever código. Esse é um elemento essencial para a sustentabilidade e o crescimento do projeto.
• Contribuições sem código oferecem até mesmo a pessoas não técnicas uma oportunidade de participar do open source, além de ajudarem no desenvolvimento de competências técnicas.
• Este texto pode inspirar quem tem interesse na comunidade open source e ajudar essas pessoas a encontrar formas de contribuir com a comunidade usando suas próprias habilidades.

[secret3056]

É um assunto um pouco diferente, mas há algum tempo alguém publicou um tutorial ensinando a fazer PR no README do Express.js, e isso acabou gerando centenas de PRs sem sentido.

Pull requests · expressjs/express

[mdisprgm]

Incômodo.. T_T

[edunga1]

São mais de 100 PRs, caramba.

[sagee]

Fiquei um pouco confuso por um momento sobre como participar com “barcode”... rs
Uma documentação detalhada pode, de certa forma, ser uma faca de dois gumes.
Pode até acontecer de a documentação e os screenshots ficarem tão detalhados que o desenvolvedor não tenha confiança para atualizar a documentação e acabe desistindo de fazer melhorias no desenvolvimento...

[cosine20]

É código ("não") código)

[GN⁺]

Opiniões do Hacker News

• Como autor/mantenedor de bibliotecas pequenas, confirma que, sem contribuições externas, o manual não seria tão bom quanto é hoje. O manual contribui muito para a usabilidade do projeto.

  • Como novo usuário do libcurl, conseguiu implementar rapidamente upload por FTP e adaptar para um caso de uso específico graças ao tutorial e à documentação da API.
  • Pela documentação, conseguiu perceber a falta de segurança de thread em versões antigas e alertar a equipe para atualizar.
  • A documentação é tão importante quanto o código e a suíte de testes.

• Desejos para projetos open source:

  • muitas capturas de tela
  • um README.md muito longo e detalhado
  • tutoriais, documentação de referência, documentos de design e diagramas de arquitetura
  • documentação de modelo mental explicando como o autor pensa

• Documentação, assets e afins são importantes em open source, mas também podem dar poder a não desenvolvedores e acabar prejudicando o projeto.

  • Isso pode afetar negativamente estabilidade, funcionalidade e adoção, como refazer a UX a cada release.
  • Atrai pessoas muito interessadas em política e facilita o surgimento de bikeshedding em áreas que todos acham que podem opinar.

• É bom usar plataformas de chat como Discord, Gitter e Slack para construir comunidade.

  • Isso faz com que as pessoas não hesitem em fazer perguntas no repositório.
  • Muitas vezes parece sem sentido fazer perguntas no GitHub ou abrir pull requests para resolver problemas.
  • Entre criadores de projetos no GitHub, é bastante difundida a atitude de "já publiquei o código, então não devo nada além disso".

• Com base na experiência atuando na comunidade WordPress, considera que a documentação inicial e a documentação forte do Codex contribuíram muito para o crescimento do WordPress.

  • Na época em que Joomla, Drupal e WordPress tinham bases instaladas semelhantes, era mais fácil começar com WordPress graças à abundância de documentação.

• O maior desejo para projetos open source é que as pessoas os usem e deixem algum tipo de registro sobre esse uso.

  • Deixar uma mensagem no canal de Discord do projeto, ou um tweet, mensagem curta, captura de tela, gist, repositório público no GitHub, vídeo no YouTube ou TikTok, tudo isso é uma contribuição muito valiosa para o projeto.

• Não tem certeza se contribuições não relacionadas a código são o segredo do sucesso de um projeto, mas concorda que são muito importantes.

  • Por exemplo, a Eclipse Foundation lembra aos usuários que relatórios de bugs também são contribuições valiosas.

• No processo de iniciar um projeto open source, há a expectativa de que haverá 10 vezes mais engenheiros usando o software do que engenheiros efetivamente escrevendo código.

  • Os usuários devem poder contribuir melhorando a documentação.
  • Ao gerar documentação (manual do usuário) com um gerador de site estático como Hugo, é preciso haver um meio de os usuários enviarem correções/atualizações para a documentação sem precisar abrir uma issue no GitHub.

• Se pessoas não técnicas conseguem entender o projeto e encontrar valor nele, isso é um bom indicador de que o projeto pode ter sucesso.

• A documentação é importante na transição de um estágio em que o produto é usado por fãs, ainda pouco conhecido, para um estágio em que se busca mais usuários.

  • Sem boa documentação, é difícil passar dessa fase.
  • Isso serve de lembrete de que é preciso escrever um guia do usuário para o Neural Amp Modeller.