Ter pessoas colaborando vai trazer melhorias para o seu pacote e, se você integrar algumas delas como autoras do pacotes com permissões de escrita no repositório, seu pacote será desenvolvido de forma mais sustentável. Também pode ser muito agradável trabalhar em equipe!
Além dessas dicas técnicas, é importante lembrar-se de ser gentil e levar em conta a perspectiva das outras pessoas, especialmente quando as prioridades delas forem diferentes das suas.
11.1 Torne a contribuição e a colaboração do seu repositório amigáveis
11.1.1 Código de conduta
Após a transferência para a nossa organização no GitHub, o Código de Conduta da rOpenSci será aplicado ao seu projeto. Você deve adicionar este texto ao README:
Please note that this package is released with a [ContributorCode of Conduct](https://ropensci.org/code-of-conduct/). Bycontributing to this project, you agree to abide by its terms.
Em seguida, exclua o código de conduta atual do pacote, caso exista algum.
11.1.2 Guia de contribuição
Você pode usar a issue, a solicitação de pull request e as diretrizes de contribuição. Ter um arquivo sobre contribuição como .github/CONTRIBUTING.md ou docs/CONTRIBUTING.md é obrigatório. Uma maneira fácil de inserir um modelo para um guia de contribuição é usar a função use_tidy_contributing() do pacote usethis que insere este modelo como .github/CONTRIBUTING.md. Um exemplo mais completo é este modelo de Peter Desmet ou as abrangentes páginas da wiki do pacote mlr3 no GitHub. Em geral, esses e outros modelos precisarão ser modificados para serem usados com um pacote da rOpenSci, principalmente por meio de referências e links para o nosso Código de Conduta conforme descrito em um outro lugar neste livro. Modificar um guia de contribuição genérico para adicionar um toque pessoal também tende a fazer com que ele pareça menos genérico e mais sincero. As preferências pessoais em um guia de contribuição incluem:
Criação de contas de sandbox? Mocking em testes? Links para documentos externos?
A rOpenSci também incentiva os guias de contribuição a incluírem uma declaração de ciclo de vida que esclareça as visões e expectativas para o desenvolvimento futuro do seu pacote, como neste exemplo. É necessário que os pacotes estatísticos tenham uma declaração de ciclo de vida, conforme especificado em Padrões estatísticos gerais G1.2. Esses links fornecem um modelo para uma declaração de ciclo de vida simples. Os arquivos CONTRIBUTING.md também podem descrever como você reconhece as contribuições (consulte esta seção).
Recomendamos que você envie comentários que não sejam um relatório de bug ou uma solicitação de feature para o Fórum da rOpenSci após certificar-se de que você verá essas perguntas no fórum. As pessoas usuárias podem usar o fórum para fazer perguntas sobre o uso e relatar seus casos de uso, e você pode se inscrever em categorias e tags individuais para receber notificações sobre o seu pacote. Sinta-se à vontade para mencionar isso nos documentos do seu pacote e/ou nas diretrizes de contribuição/modelo de issue. Oriente as pessoas que usam seu pacote a marcar as mensagens com o nome do pacote.
Ao usar os recursos do GitHub em torno dos issues, você pode ajudar os possíveis colaboradores a encontrá-los e tornar público o seu roteiro.
11.1.3.1 Modelos de issues
Você pode usar um ou vários modelo(s) de issue(s) para ajudar as pessoas usuárias a preencherem os relatórios de bugs ou as solicitações de feature. Quando há vários modelos de issues, os usuários que clicam em abrir uma nova issue veem um menu que orienta as suas escolhas.
Você pode até configurar uma das opções para apontar para algum lugar fora do seu repositório (por exemplo, um fórum de discussão).
Você pode fixar até 3 issues por repositório que aparecerão na parte superior do seu rastreador de issues como cartões de issues bonitos. Isso pode ajudar a divulgar quais são suas prioridades.
11.1.3.4 Marcos
Você pode criar marcos e atribuir problemas a eles, o que ajuda outras pessoas a verem o que você planeja para a próxima versão do seu pacote, por exemplo.
11.1.4 Comunicação com as pessoas usuárias
Você pode indicar para as pessoas usuárias o fórum da rOpenSci se você monitorar ou ativar as Discussões no GitHub para o repositório do seu pacote. Cada discussão do GitHub pode ser convertida em um issue, se necessário (e vice-versa, os issues podem ser convertidos em discussões).
11.2 Trabalhando com colaboradores
Em primeiro lugar: mantenha contato com o seu repositório do GitHub!
Não se esqueça de observar o seu repositório do GitHub para receber notificações sobre issues ou pull requests (como alternativa, se você trabalha de forma concentrada em certas épocas, talvez adicione essas informações ao guia de contribuição).
não se esqueça de enviar as atualizações que você tem localmente.
desative os testes com falha se você não puder corrigí-los, pois eles criam ruído nos PRs que podem confundir colaboradores iniciantes.
11.2.1 Integração de pessoas colaboradoras
Não existe uma regra geral da rOpenSci sobre como você deve integrar pessoas colaboradoras. Você deve aumentar os direitos delas sobre o repositório à medida que ganhar confiança e, sem dúvida, deve reconhecer as contribuições que fizerem (consulte esta seção).
Você pode pedir a um novo colaborador que crie PRs (consulte a seção a seguir para avaliar um PR localmente, ou seja, além das verificações de CI) para dev/main e avalie-os antes de mesclá-los e, depois de algum tempo, deixe-os enviar para o main, embora você possa querer manter um sistema de revisões de PRs… mesmo para si mesmo quando tiver colegas de equipe!
Um modelo possível para a integração de pessoas colaboradoras é fornecido por Jim Hester em seu lintr repo.
Se o seu problema for o recrutamento de pessoas colaboradoras, você pode publicar uma chamada aberta como a de Jim Hester no Twitter, ou no GitHub e, como autor(a) de um pacote da rOpenSci, você pode pedir ajuda no slack da rOpenSci e pedir à equipe da rOpenSci por ideias para recrutar novas pessoas colaboradoras.
11.2.2 Trabalhando com colaboradores (incluindo você)
Branchs (ou ramificações) são baratas. Use-as extensivamente ao desenvolver recursos, testar novas ideias e corrigir problemas.
Uma das branches é a branchmain (que é a ramificação padrão/principal), na qual, se você seguir desenvolvimento baseado no tronco você “faz merge de atualizações pequenas e frequentes”. Veja também as documentações do Fluxo do GitHub e do fluxo do GitLab. Talvez você também queira incrementar frequentemente os números da versão de seu pacote (em DESCRIPTION). Um aspecto específico do trabalho com colaboradores é a revisão de Pull requests, com algumas orientações úteis em:
Se alguém contribuir para o seu repositório, considere adicioná-la em DESCRIPTION, como contribuinte (“ctb”) para pequenas contribuições, e autor (“aut”) para contribuições maiores. Tradicionalmente, ao citar um pacote em uma publicação científica, apenas as pessoas autoras “aut” são listados, e não as contribuidores “ctb”; e em pkgdown e, nos sites, somente os nomes “aut” são listados na página inicial, e todas as pessoas autoras são listados na página de autores.
No mínimo, considere adicionar o nome das pessoas colaboradoras próximo à linha de correção de feature/bugs em NEWS.md.
Recomendamos que você seja generoso(a) com esses agradecimentos, porque é uma coisa boa de se fazer e porque isso aumentará a probabilidade de as pessoas contribuírem novamente com o seu pacote ou com outros repositórios da organização.
Como um lembrete de nossas diretrizes de empacotamento se o seu pacote foi revisado e você acha que as pessoas revisoras fizeram uma contribuição substancial para o desenvolvimento do seu pacote, você pode listá-las na seção Authors@R com um tipo de contribuinte “Revisor” ("rev"), da seguinte forma:
person("Bea", "Hernández", role = "rev",
comment = "Bea reviewed the package (v. X.X.XX) for rOpenSci, see <https://github.com/ropensci/software-review/issues/116>"),
Por favor, não liste os editores como colaboradores. Sua participação e contribuição para a rOpenSci são agradecimentos suficientes!
11.2.4 Dando as boas-vindas aos colaboradores da rOpenSci
Se você conceder a alguém permissões de escrita no repositório,
entre em contato com um membro da equipe para que esse novo colaborador possa receber um convite para a organização da rOpenSci no GitHub (em vez de ser um colaborador externo)
entre em contato com a equipe da rOpenSci ou um outro membro da equipe para que esse novo colaborador possa receber um convite para o workspace do Slack da rOpenSci.