terça-feira, 19 de setembro de 2023 From rOpenSci (https://ropensci.org/pt/blog/2023/09/19/help-wanted/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
A manutenção de um pacote pode ser uma atividade solitária, o que às vezes representa um problema se você preferir trabalhar em equipe ou se encontrar um problema muito espinhoso para você. Além de pertencer a uma comunidade de pessoas mantenedoras (como a rOpenSci 😉), para obter ajuda e solidariedade colaborativa, você pode tentar criar uma comunidade de pessoas colaboradoras em torno do seu pacote! Nesta publicação, exploraremos uma ferramenta que ajudará você a atingir esse objetivo: as issues marcadas como “procura-se ajuda” (“help wanted”), com os quais seu repositório pode atrair e manter novas pessoas desenvolvedoras! Discutiremos o que são issues de “procura-se ajuda”, quais são as quatro etapas para solicitar ajuda externa e lembraremos que esse pode ser um processo benéfico, mesmo que você não acabe atraindo ajuda.
Observe que esta postagem usa a terminologia específica do GitHub, como issues e labels. Se você usa o GitLab ou outra plataforma git, provavelmente há um equivalente. 🙂
As issues “procura-se ajuda” são issues para as quais você aceitaria ou precisaria de contribuições externas.
Elas são rotuladas com a label padrão da comunidade “help wanted” (em inglês) (exemplo; opcionalmente com um emoji, se você executou usethis::use_tidy_github_labels()).
Para alguns desses casos, quando a tarefa não é muito complexa, ou quando serve como uma boa porta de entrada para sua quem está conhecendo o código, você também pode usar a label “good first issue” (bom primeiro problema).
A seguir, abordaremos quatro etapas para solicitar ajuda externa.
Às vezes, um obstáculo com o qual você não sabe como lidar aparece no caminho para o seu próximo marco de desenvolvimento. Nesse estágio, você pode
Por exemplo, ao trabalhar no pacote tinkr, Maëlle abriu uma issue muito específica que acabou recebendo uma ajuda externa milagrosa.
Você também pode adicionar a label “procura-se ajuda” a um informe de erro ou solicitação de funcionalidade que outra pessoa abriu em seu pacote! Com um pouco de sorte, a própria pessoa que criou a issue poderá participar.
Às vezes, há algumas ideias de manutenção ou aprimoramento que você tem para o seu pacote e para as quais não tem tempo no momento ou que não são urgentes. Por exemplo, atualizar a infraestrutura de testes para utilizar a terceira edição do pacote testthat ou adicionar suporte do pacote terra a um pacote espacial. Ao adicioná-los em sua lista de issues,
Quando você tiver um tópico em mente, deixe o título e o texto da issue o mais claro possível. Mesmo que você seja a única pessoa a corrigir o problema no final, no futuro você ficará feliz por não ter anotado um comentário indecifrável. Se necessário, faça links para recursos e certifique-se de incluir o contexto. Aborde a redação de uma issue em seu próprio repositório da mesma forma que você faria em um repositório que não é seu: descrição do desafio, resultado desejado, perdas e ganhos (trade-offs), etc.
Além dos esforços em uma issue individual, é fundamental que você tenha um guia de contribuição destacando tudo o que é necessário saber sobre como contribuir para o seu pacote: ferramentas usadas, e preferências de estilo e design. 1 Não duplique recursos externos; em vez disso, faça um link para eles. Tente ser um pouco flexível para não sobrecarregar ou assustar as pessoas colaboradoras com requisitos muito rígidos: você provavelmente pode terminar os PRs sozinho ou ensiná-los aos poucos.
Em primeiro lugar, para os pacotes da rOpenSci, as issues marcadas com a label “procura-se ajuda” são transmitidas para a comunidade por meio do site e de publicações nas mídias sociais!
Você também pode compartilhá-lo em suas próprias redes: no slack da rOpenSci, em suas redes sociais, um canal de comunicação local de pessoas usuárias de R, etc.
Você também pode considerar a possibilidade de aproveitar eventos hack-a-thon como Hacktoberfest por exemplo (se você adicionar a label “hacktoberfest” ao seu repositório), mas em eventos realmente grandes como esse você não pode necessariamente contar que alguém descubra sua pequena issue nesse mar de issues.
Se alguém responder a uma issue ou abrir um pull request, tente ser manter uma postura acolhedora. Verifique se suas configurações permitem que você receba notificações sobre comentários de issues e PRs. Talvez seja necessário habilitar a opção watch no seu repositório.
Reconheça contribuições generosamente!
Mesmo que você tenha escrito uma excelente issue, talvez ela não seja escolhida. Nesse caso, considere a possibilidade de fazer uma nova divulgação, peça dicas gerais para as pessoas mantenedoras que você conhece e considere a possibilidade de solicitar um financiamento (portanto, tempo, seu ou de uma pessoa externa contratada) para seus esforços de manutenção. Por exemplo, o site da R Consortium abre uma chamada para solicitar propostas de financiamento duas vezes por ano.
Mesmo que ninguém resolva a issue no final, passar por esse processo pode ser útil, pois dá a você a chance de pensar detalhadamente sobre o problema e considerar possíveis resoluções, o que pode ajudá-lo a resolver o problema por conta própria. Além disso, uma issue bem documentada é uma ótima maneira de documentar suas decisões sobre o software de forma transparente e pode ajudar futuras pessoas usuárias e colaboradoras a entender os motivos das suas escolhas.
Abrir issues de “procura-se ajuda” pode ser uma forma de aumentar a comunidade de pessoas colaboradoras do seu pacote. Elas podem ser uma porta de entrada melhor para a contribuição do que issues menos específicas com uma lista de tarefas necessárias, já que são menos sobrecarregadas. As pessoas colaboradoras podem consertar uma issue marcada como “procura-se ajuda” e depois parar, ou continuar e resolver mais issues. Às vezes, uma conversa nos comentários pode ajudar você a encontrar uma solução, mesmo que uma pessoa colaboradora envie um PR.
Como pessoa colaboradora, sempre comente em uma issue antes de resolvê-lo, para garantir que ela ainda esteja atualizada e que ninguém mais esteja preparando um PR duplicado no momento! Como seria irritante se você trabalhasse para nada.
Para obter mais informações sobre como fomentar uma comunidade em torno do seu pacote, você pode aproveitar a gravação e os materiais em nossa passada chamada da comunidade sobre o tema.
Você pode achar https://contributing.streamlit.app/ útil, mas outra maneira de aprimorar seu guia de contribuição é continuar a alterá-lo com base na sua experiência com novas colaborações. ↩︎
