sexta-feira, 17 de maio de 2024 From rOpenSci (https://ropensci.org/pt/blog/2024/05/17/communica-dicas-oss-projeto/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
Você mantém um projeto de código aberto, como um pacote R ou um conjunto de pacotes, e quer saber como usar melhor os vários canais de comunicação para informar e interagir com a sua comunidade de pessoas usuárias? Consolidamos esta lista de dicas para você. Em nossa opinião, algumas delas são obrigatórias, enquanto outras são desejáveis.
Como você está desenvolvendo um produto, o primeiro ato de comunicação é escrever notas de versão (release notes) informativas.
As notas de versão geralmente descrevem atualizações e alterações, geralmente em um arquivo chamado NEWS.md. Esses arquivos geralmente têm um cabeçalho por versão, com subcabeçalhos usados para agrupar as alterações em categorias significativas.
Os recursos para você começar a usar as notas de versão incluem:
usethis::use_news_md() para criar o arquivo NEWS.md.Você pode automatizar parcialmente as notas de versão a partir de mensagens de commit usando, por exemplo, o pacote fledge (bastante poderoso quando usado em conjunto com a convenção de commits convencionais (Conventional Commits)).
As notas de versão podem informar diretamente as pessoas usuárias, que podem lê-las:
NEWS.md em uma página chamada changelog.Eles também serão úteis como matéria-prima para outras iniciativas de comunicação, como postagens em blogs sobre lançamentos.
Seus repositórios não devem ter apenas rastreadores de issues/tickets, mas você também deve garantir que um número suficiente de pessoas que fazem parte da equipe os acompanhem ou analisem novos tickets ou comentários pelo menos de vez em quando. Manter e responder a issues é uma parte importante da manutenção de uma comunidade de pessoas usuárias.
O uso de issues pelo seu projeto pode ser divulgado por meio de uma issue fixada; você pode até mesmo limitar temporariamente as interações. Esses termos e links são para o GitHub, mas existem ideias e funcionalidades semelhantes para outras plataformas de hospedagem de código.
Todo software de código aberto tem um perfil, possivelmente espalhado por vários lugares, como organizações do GitHub ou contas do Mastodon. Um logotipo pode ser um identificador importante do seu perfil e deve aparecer de forma consistente em todos os seus perfis. Também é importante incluir descrições informativas e verificar todas as URLs (documentação para o GitHub, documentação para o Mastodon).
No caso de uma organização no GitHub, você pode perguntar aos seus membros se eles gostariam de tornar sua afiliação à organização do GitHub pública, o que pode transmitir uma imagem mais colaborativa, mesmo antes que alguém examine a atividade de commits.
O polimento do perfil não precisa levar muito tempo e só pode melhorar a imagem do seu projeto.
Para qualquer plataforma que exija logins ou algum tipo de permissão de acesso, certifique-se de que todas as pessoas que precisam de acesso o tenham e que o acesso seja removido de qualquer pessoa que não precise mais dele.
Você pode considerar o uso de sistemas de gerenciamento de senhas, como o 1Password.
Como a composição de uma equipe de desenvolvimento muda com o tempo, é aconselhável revisar o acesso regularmente e fazer com que essa revisão faça parte de algum tipo de lista de tarefas de integração/desligamento (onboarding/offboarding) de pessoas na equipe.
Embora o desenvolvimento de código aberto exija que muita coisa aconteça em um ambiente aberto, também é importante cultivar um espaço seguro onde as pessoas da equipe possam desabafar, discutir assuntos delicados ou compartilhar fotos de animais de estimação. Isso pode ser feito por meio de um espaço de trabalho do Slack, Discord, Matrix ou servidor Element, ou por opções de ponta como o flat ou CQ2.
O ideal é que você seja a pessoa proprietária do espaço, a menos que possa contar com um parceiro externo (um financiador? uma coalizão maior de projetos?) para continuar fornecendo-o a você.
Para um projeto pequeno, os rastreadores de issues podem ser tudo o que você precisa para lidar com relatórios de bugs, pedidos de funcionalidades e perguntas e respostas em geral. No entanto, projetos maiores podem se beneficiar da criação e da curadoria de um fórum de discussão dedicado.
Você pode usar Discourse ou o GitHub Discussions.
Em comparação com as notas de versão, as postagens de blog sobre novas versões fornecem mais uma narrativa e, portanto, podem ser mais fáceis de ler. Eles ainda podem direcionar as pessoas usuárias às notas de versão para obter mais informações.
O blog de um projeto de código aberto também pode conter outros tipos de publicações, como um aprofundamento em uma funcionalidade, anúncio de financiamento, solicitação de contribuições ou apoio financeiro.
Ao escolher um construtor de sites, tente escolher um que seja gratuito e que seja familiar para a equipe do seu projeto ou fácil o suficiente para que você se familiarize com ele. As postagens de blog baseadas em Markdown são mais fáceis de escrever a partir de notas de versão. Certifique-se também de que a publicação de uma nova postagem no blog não seja um processo complicado de 100 etapas, ou ninguém vai querer escrever uma. Você pode optar por usar o GitHub para o processo de revisão e pré-visualização de posts de blog.
Se você criar um blog, certifique-se de criar também um feed RSS para ele. Na maioria dos geradores de sites estáticos, isso é padrão ou está disponível quando você ativa uma opção (documentação do Quarto).
Quando o seu blog tiver um feed RSS, registre-o em agregadores relevantes, como R Weekly no mundo do R.
Se você optar por habilitar comentários nas postagens do blog, certifique-se de integrá-los ao fórum do projeto.
Isso é muito fácil com o Discourse (que usamos neste mesmo blog) e o GitHub Discussions via Giscus (que também são fáceis de integrar com o Quarto, entre outros).
Integrar os comentários ao fórum significa que você só precisa acompanhar um único espaço e também ajuda a conectar as pessoas leitoras dos posts do blog ao fórum.
As redes sociais podem ser úteis para divulgar o seu projeto e suas atualizações, e para interagir com as pessoas usuárias. Você pode optar por tornar suas redes “apenas para divulgação”, deixando claro que não tem disponibilidade para responder a perguntas por meio delas.
O ideal é que você concentre o uso da mídia social em plataformas agradáveis e plataformas em que os usuários e a comunidade de seus projetos provavelmente se reunirão.
Nesta publicação, compartilhamos algumas dicas de comunicação para o seu projeto de código aberto. Use os canais de comunicação de acordo com os objetivos e os recursos do seu projeto. Você também pode se interessar por nossa chamada comunitária anterior: Configure seu pacote para fomentar uma comunidade.
