From a5204147e6ccb28f4e48e72d38f263f4af0bd5d3 Mon Sep 17 00:00:00 2001 From: Yanina Bellini Saibene Date: Fri, 29 Aug 2025 14:09:13 -0300 Subject: [PATCH 1/2] Portuguese translation what it is to be a maintainer --- .../index.pt.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md diff --git a/content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md b/content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md new file mode 100644 index 0000000000..10016f2045 --- /dev/null +++ b/content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md @@ -0,0 +1,77 @@ +--- +title: What Does It Mean to Maintain a Package? +author: + - Maëlle Salmon +date: '2023-02-07' +slug: what-does-it-mean-to-maintain-a-package +categories: + - blog +tags: + - package + - maintenance +package_version: 0.1.0 +description: An attempt to define what package maintenance entails, with a few tips. +params: + doi: "10.59350/vv6xb-53139" +--- + +Part of what we aim to do at rOpenSci is nurture a community of package maintainers who help each other. +In addition to support during package maintenance, we also want to support maintainers who wish to move on. Situations can change, and there may come a time when a maintainer is looking to pass maintenance on to another. If a maintainer finds themself in this situation and would like to transfer maintainership, we help by [advertising](/blog/2022/10/17/maintain-or-co-maintain-an-ropensci-package/), and also help the new maintainer(s) with advice, generally à la "look around to see if anything needs fixing, then do routine maintenance". +But what is routine maintenance? This post is an attempt to define what package maintenance entails, with a few tips. + +## Package maintenance as ownership + +As a package maintainer (or maintainer team), + ++ you are responsible for the scope of the package: Want to add a feature? Your call! ++ you are in charge of planning work on the codebase: Think of improvements and organize them into milestones. ++ you are in control of code quality: Want to spend more time on this pull request? Or will you accept and accrue a bit of [technical debt](https://en.wikipedia.org/wiki/Technical_debt)? Again, your call! + +However you do not own only these technical and productivity aspects. +In our past community call about [Maintaining an R Package](/commcalls/2020-03-18/), Erin Grand defined maintaining a package as "ownership around package community". +What a great way to recognize the _people_ creating and using a piece of software! +As a package maintainer, one of your roles is to support and encourage a thriving community of users and contributors... Also the topic of a former community call: [Set Up Your Package to Foster a Community](/commcalls/apr2021-pkg-community/). + +## Package maintenance as responsiveness + +Now, unfortunately, you do not own the whole agenda of package maintenance. :sweat_smile: +Unless your package has no visible users, your maintenance work will likely some sort of user support and issue triage. +You might also get requests from the maintainers of dependencies of your package, or from the repository you publish your package with (CRAN, Bioconductor). + +User support in particular can be a source of joy, seeing your package used, helping people get through hurdles, problem solving. +However, all these external demands can be exhausting and even stressful. +How can we prevent this? +Well, unfortunately, this is a common situation. However, while there is no magical solution, here are things that might help. + +* Maintaining the package as a team can help share the load, and can also provide a back channel to let off some steam. If you're feeling like you could use some hands-on support, consider inviting some co-maintainers to the project. +* If you want support, but not necessarily the hands-on type, consider chatting with other maintainers. You can discuss specific bugs or coding problems, or general tips for community management or engagement. You can even just share some woes and get sympathy 😁. rOpenSci has a #package-maintenance channel in its [semi-open slack](https://contributing.ropensci.org/resources.html#channels), which all rOpenSci package maintainers should have access to (please email us if not). +* You don't need to address all issues as soon as they pop up (apart from CRAN's strict deadlines, that is). You can plan periods of activity and inactivity in your repository, potentially indicating this clearly in a pinned issue or in the documentation. The targets manual explains [out of office periods](https://books.ropensci.org/targets/help.html#out-of-office) but out of office could also very well be your package's more usual state, with activity in bursts. Your package, your choice! +* You can adjust your contributing guidelines over time. There is no shame in asking a user to provide a reprex versus spending hours guessing the meaning of their issue text. Through contributing guidelines and gentle explanations, you can shift general questions about your package to a place where it's easier for you, for instance GitHub Discussions as opposed to Issues. +* Make sure you catch notifications (is your right email address listed, do you watch your own repository?). You don't need to read or act on them immediately but it's nice to not lose them. +* You can choose where your package is published. If the rules of a publication repository are a source of too much pain compared to the ease of distribution, you can choose to leave it. +* You might also try to find funding for your work. See for instance the [R Consortium call for proposals](https://www.r-consortium.org/all-projects/call-for-proposals) (twice a year). + +## Package maintenance as housekeeping + +Beside exciting feature requests, package maintenance often warrants more "routine" work. + +You might want to try to keep up to date with package development best practice (and external guidelines :sweat_smile:) through package development channels. +Remember [rOpenSci newsletter](/news) has a Package Development Corner. :wink: +Following questions on, say, the [rOpenSci forum](https://discuss.ropensci.org/) or Posit community forum [Package Development category](https://community.rstudio.com/c/package-development/11) can be a form of news monitoring and deliberate practice. +With such reading/following, you might reach a new understanding of a testing method, you might discover a dependency is best switched for another, etc. + +Now, when and how do you improve your package? +You might try and repay some technical debt each time you plan some work on a feature. +You might imitate the [tidyverse spring cleaning](/blog/2022/03/18/ropensci-news-digest-march-2022/#get-inspired-by-the-tidyverse-spring-cleaning), both the idea of it and the actual items listed in the public checklist, like updating continuous integration setups. +If such work does not sound fun, again doing it as a team might help, or you might join an [rOpenSci co-working event](/events) to give yourself a dedicated time for working on regular package maintenance in a fun environment. + +## Conclusion + +In this post we tried giving an overview of what maintaining a package entails: ownership of the scope, code and community; self-controlled responsiveness to external requests; regular housekeeping. +All of this can be a lot of work, and needs to be balanced against the rewards one gets as a package developer (depending on your situation these might entail: personal satisfaction of creating an useful tool; joy of collaborating with others; income; developing coding experience; demonstrating your skills; getting recognition for your work). + +If the balance feels off, consider your needs. It might be time to try and recruit co-maintainers or join a community of other developers, or even to find a new maintainer or retire the package. +For rOpenSci packages, we can help by advertising your package's need for help, so feel free to contact us. +Last but not least, we at rOpenSci would like to thank all package maintainers, past, present and future! The work you do, have done, or will do, is valuable and awesome, and we really appreciate it 🙏🏼 ! + +We are always trying to think about ways to support package maintainers. Please feel free to add a comment below with any suggestions you might have. From 1e9d27e6c5655ac4e02af8790af2e8d3fe8cb200 Mon Sep 17 00:00:00 2001 From: Yanina Bellini Saibene Date: Fri, 29 Aug 2025 14:09:53 -0300 Subject: [PATCH 2/2] Portuguese --- .../index.pt.md | 105 +++++++++--------- 1 file changed, 54 insertions(+), 51 deletions(-) diff --git a/content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md b/content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md index 10016f2045..27a5e65e03 100644 --- a/content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md +++ b/content/blog/2023-02-07-what-does-it-mean-to-maintain-a-package/index.pt.md @@ -1,77 +1,80 @@ --- -title: What Does It Mean to Maintain a Package? +title: O que significa manter um pacote? author: - - Maëlle Salmon +- Maëlle Salmon date: '2023-02-07' slug: what-does-it-mean-to-maintain-a-package categories: - - blog +- blog tags: - - package - - maintenance +- package +- maintenance package_version: 0.1.0 -description: An attempt to define what package maintenance entails, with a few tips. +description: Uma tentativa de definir o que significa a manutenção de pacotes, com + algumas dicas. params: - doi: "10.59350/vv6xb-53139" + doi: 10.59350/vv6xb-53139 --- -Part of what we aim to do at rOpenSci is nurture a community of package maintainers who help each other. -In addition to support during package maintenance, we also want to support maintainers who wish to move on. Situations can change, and there may come a time when a maintainer is looking to pass maintenance on to another. If a maintainer finds themself in this situation and would like to transfer maintainership, we help by [advertising](/blog/2022/10/17/maintain-or-co-maintain-an-ropensci-package/), and also help the new maintainer(s) with advice, generally à la "look around to see if anything needs fixing, then do routine maintenance". -But what is routine maintenance? This post is an attempt to define what package maintenance entails, with a few tips. +Parte do que pretendemos fazer na rOpenSci é cultivar uma comunidade de mantenedores de pacotes que se ajudam mutuamente. +Além do suporte durante a manutenção do pacote, também queremos dar suporte aos mantenedores que desejam seguir em frente. As situações podem mudar e pode chegar um momento em que um mantenedor queira passar a manutenção para outro. Se um mantenedor se encontrar nessa situação e quiser transferir a manutenção, nós o ajudaremos da seguinte forma [publicidade](/blog/2022/10/17/maintain-or-co-maintain-an-ropensci-package/) e também ajudamos o(s) novo(s) mantenedor(es) com conselhos, geralmente do tipo "olhe ao redor para ver se há algo que precise de conserto e, em seguida, faça a manutenção de rotina". +Mas o que é manutenção de rotina? Esta postagem é uma tentativa de definir o que significa manutenção de pacotes, com algumas dicas. -## Package maintenance as ownership +## Manutenção de pacotes como propriedade -As a package maintainer (or maintainer team), +Como mantenedor de pacotes (ou equipe de mantenedores), -+ you are responsible for the scope of the package: Want to add a feature? Your call! -+ you are in charge of planning work on the codebase: Think of improvements and organize them into milestones. -+ you are in control of code quality: Want to spend more time on this pull request? Or will you accept and accrue a bit of [technical debt](https://en.wikipedia.org/wiki/Technical_debt)? Again, your call! +- você é responsável pelo escopo do pacote: Você quer adicionar um recurso? A decisão é sua! +- você está encarregado de planejar o trabalho na base de código: Você deve pensar em melhorias e organizá-las em marcos. +- você está no controle da qualidade do código: Você quer dedicar mais tempo a esse pull request? Ou você aceitará e acumulará um pouco de [dívida técnica](https://en.wikipedia.org/wiki/Technical_debt)? Novamente, a decisão é sua! -However you do not own only these technical and productivity aspects. -In our past community call about [Maintaining an R Package](/commcalls/2020-03-18/), Erin Grand defined maintaining a package as "ownership around package community". -What a great way to recognize the _people_ creating and using a piece of software! -As a package maintainer, one of your roles is to support and encourage a thriving community of users and contributors... Also the topic of a former community call: [Set Up Your Package to Foster a Community](/commcalls/apr2021-pkg-community/). +No entanto, você não possui apenas esses aspectos técnicos e de produtividade. +Em nossa chamada da comunidade anterior sobre [Manutenção de um pacote R](/commcalls/2020-03-18/) Erin Grand definiu a manutenção de um pacote como "propriedade em torno da comunidade do pacote". +Que ótima maneira de reconhecer a *pessoas* que criam e usam um software! +Como mantenedor de pacotes, uma das suas funções é apoiar e incentivar uma comunidade próspera de usuários e colaboradores... Você também é o tema de uma chamada anterior da comunidade: [Configure seu pacote para promover uma comunidade](/commcalls/apr2021-pkg-community/). -## Package maintenance as responsiveness +## Manutenção de pacotes como capacidade de resposta -Now, unfortunately, you do not own the whole agenda of package maintenance. :sweat_smile: -Unless your package has no visible users, your maintenance work will likely some sort of user support and issue triage. -You might also get requests from the maintainers of dependencies of your package, or from the repository you publish your package with (CRAN, Bioconductor). +Agora, infelizmente, você não possui toda a agenda de manutenção de pacotes. :sweat\_smile: +A menos que seu pacote não tenha usuários visíveis, seu trabalho de manutenção provavelmente será algum tipo de suporte ao usuário e triagem de problemas. +Você também pode receber solicitações dos mantenedores das dependências do seu pacote ou do repositório em que você publicou o pacote (CRAN, Bioconductor). -User support in particular can be a source of joy, seeing your package used, helping people get through hurdles, problem solving. -However, all these external demands can be exhausting and even stressful. -How can we prevent this? -Well, unfortunately, this is a common situation. However, while there is no magical solution, here are things that might help. +O suporte ao usuário, em particular, pode ser uma fonte de alegria: ver o seu pacote sendo usado, ajudar as pessoas a superar obstáculos, resolver problemas. +Entretanto, todas essas demandas externas podem ser exaustivas e até mesmo estressantes. +Como podemos evitar isso? +Bem, infelizmente, essa é uma situação comum. No entanto, embora não exista uma solução mágica, aqui estão algumas coisas que podem ajudar. -* Maintaining the package as a team can help share the load, and can also provide a back channel to let off some steam. If you're feeling like you could use some hands-on support, consider inviting some co-maintainers to the project. -* If you want support, but not necessarily the hands-on type, consider chatting with other maintainers. You can discuss specific bugs or coding problems, or general tips for community management or engagement. You can even just share some woes and get sympathy 😁. rOpenSci has a #package-maintenance channel in its [semi-open slack](https://contributing.ropensci.org/resources.html#channels), which all rOpenSci package maintainers should have access to (please email us if not). -* You don't need to address all issues as soon as they pop up (apart from CRAN's strict deadlines, that is). You can plan periods of activity and inactivity in your repository, potentially indicating this clearly in a pinned issue or in the documentation. The targets manual explains [out of office periods](https://books.ropensci.org/targets/help.html#out-of-office) but out of office could also very well be your package's more usual state, with activity in bursts. Your package, your choice! -* You can adjust your contributing guidelines over time. There is no shame in asking a user to provide a reprex versus spending hours guessing the meaning of their issue text. Through contributing guidelines and gentle explanations, you can shift general questions about your package to a place where it's easier for you, for instance GitHub Discussions as opposed to Issues. -* Make sure you catch notifications (is your right email address listed, do you watch your own repository?). You don't need to read or act on them immediately but it's nice to not lose them. -* You can choose where your package is published. If the rules of a publication repository are a source of too much pain compared to the ease of distribution, you can choose to leave it. -* You might also try to find funding for your work. See for instance the [R Consortium call for proposals](https://www.r-consortium.org/all-projects/call-for-proposals) (twice a year). +- A manutenção do pacote como uma equipe pode ajudar a dividir a carga e também pode fornecer um canal de apoio para você desabafar. Se você achar que precisa de algum suporte prático, considere convidar alguns co-mantenedores para o projeto. +- Se você quiser suporte, mas não necessariamente do tipo prático, considere a possibilidade de conversar com outros mantenedores. Você pode discutir bugs específicos ou problemas de codificação, ou dicas gerais para gerenciamento ou envolvimento da comunidade. Você pode até mesmo compartilhar alguns problemas e obter simpatia. O rOpenSci tem um canal #package-maintenance em seu [slack semiaberto](https://contributing.ropensci.org/resources.html#channels) ao qual todos os mantenedores de pacotes da rOpenSci devem ter acesso (caso contrário, envie-nos um e-mail). +- Você não precisa resolver todos os problemas assim que eles surgirem (além dos prazos rigorosos do CRAN, é claro). Você pode planejar períodos de atividade e inatividade no seu repositório, possivelmente indicando isso claramente em um problema fixado ou na documentação. O manual de metas explica [períodos de ausência do escritório](https://books.ropensci.org/targets/help.html#out-of-office) mas a inatividade também pode muito bem ser o estado mais comum do seu pacote, com atividade em rajadas. Seu pacote, sua escolha! +- Você pode ajustar suas diretrizes de contribuição ao longo do tempo. Não é vergonha nenhuma pedir a um usuário que forneça uma resposta em vez de passar horas tentando adivinhar o significado do texto do problema. Por meio de diretrizes de contribuição e explicações gentis, você pode transferir perguntas gerais sobre o seu pacote para um local onde seja mais fácil para você, por exemplo, GitHub Discussions em vez de Issues. +- Certifique-se de receber as notificações (seu endereço de e-mail correto está listado, você observa seu próprio repositório?) Você não precisa ler ou agir sobre elas imediatamente, mas é bom não perdê-las. +- Você pode escolher onde seu pacote será publicado. Se as regras de um repositório de publicação forem uma fonte de muita dor em comparação com a facilidade de distribuição, você pode optar por deixá-lo. +- Você também pode tentar obter financiamento para o seu trabalho. Consulte, por exemplo, a seção [R Consortium call for proposals](https://www.r-consortium.org/all-projects/call-for-proposals) (duas vezes por ano). -## Package maintenance as housekeeping +## Manutenção de pacotes como serviço de limpeza -Beside exciting feature requests, package maintenance often warrants more "routine" work. +Além das solicitações de recursos interessantes, a manutenção de pacotes geralmente garante um trabalho mais "rotineiro". -You might want to try to keep up to date with package development best practice (and external guidelines :sweat_smile:) through package development channels. -Remember [rOpenSci newsletter](/news) has a Package Development Corner. :wink: -Following questions on, say, the [rOpenSci forum](https://discuss.ropensci.org/) or Posit community forum [Package Development category](https://community.rstudio.com/c/package-development/11) can be a form of news monitoring and deliberate practice. -With such reading/following, you might reach a new understanding of a testing method, you might discover a dependency is best switched for another, etc. +Você pode tentar manter-se atualizado sobre as práticas recomendadas de desenvolvimento de pacotes (e diretrizes externas :sweat\_smile:) por meio dos canais de desenvolvimento de pacotes. +Lembre-se de que você [Boletim informativo da rOpenSci](/news) tem um canto de desenvolvimento de pacotes :wink: +Após perguntas sobre, por exemplo, o [fórum rOpenSci](https://discuss.ropensci.org/) ou no fórum da comunidade Posit [Categoria de desenvolvimento de pacotes](https://community.rstudio.com/c/package-development/11) pode ser uma forma de monitoramento de notícias e prática deliberada. +Com essa leitura/acompanhamento, você pode chegar a um novo entendimento de um método de teste, pode descobrir que é melhor trocar uma dependência por outra, etc. -Now, when and how do you improve your package? -You might try and repay some technical debt each time you plan some work on a feature. -You might imitate the [tidyverse spring cleaning](/blog/2022/03/18/ropensci-news-digest-march-2022/#get-inspired-by-the-tidyverse-spring-cleaning), both the idea of it and the actual items listed in the public checklist, like updating continuous integration setups. -If such work does not sound fun, again doing it as a team might help, or you might join an [rOpenSci co-working event](/events) to give yourself a dedicated time for working on regular package maintenance in a fun environment. +Agora, quando e como você aprimora seu pacote? +Você pode tentar pagar alguma dívida técnica sempre que planejar algum trabalho em um recurso. +Você pode imitar o [limpeza de primavera do tidyverse](/blog/2022/03/18/ropensci-news-digest-march-2022/#get-inspired-by-the-tidyverse-spring-cleaning) você pode imitar a limpeza de primavera do tidyverse, tanto a ideia quanto os itens reais listados na lista de verificação pública, como a atualização das configurações de integração contínua. +Se esse trabalho não parecer divertido, novamente, fazê-lo em equipe pode ajudar, ou você pode participar de um [evento de trabalho conjunto do rOpenSci](/events) para que você tenha um tempo dedicado para trabalhar na manutenção regular de pacotes em um ambiente divertido. -## Conclusion +## Conclusão -In this post we tried giving an overview of what maintaining a package entails: ownership of the scope, code and community; self-controlled responsiveness to external requests; regular housekeeping. -All of this can be a lot of work, and needs to be balanced against the rewards one gets as a package developer (depending on your situation these might entail: personal satisfaction of creating an useful tool; joy of collaborating with others; income; developing coding experience; demonstrating your skills; getting recognition for your work). +Nesta postagem, tentamos dar uma visão geral do que significa manter um pacote: propriedade do escopo, código e comunidade; capacidade de resposta autocontrolada a solicitações externas; manutenção regular. +Tudo isso pode dar muito trabalho e precisa ser contrabalançado com as recompensas que você recebe como desenvolvedor de pacotes (dependendo da sua situação, elas podem incluir: satisfação pessoal de criar uma ferramenta útil; alegria de colaborar com outras pessoas; renda; desenvolvimento de experiência em codificação; demonstração de suas habilidades; reconhecimento do seu trabalho). + +Se você sentir que não há equilíbrio, considere suas necessidades. Talvez seja hora de tentar recrutar co-mantenedores ou participar de uma comunidade de outros desenvolvedores, ou até mesmo encontrar um novo mantenedor ou retirar o pacote. +Para os pacotes rOpenSci, podemos ajudar anunciando a necessidade de ajuda do seu pacote, portanto, sinta-se à vontade para entrar em contato conosco. +Por último, mas não menos importante, nós da rOpenSci gostaríamos de agradecer a todos os mantenedores de pacotes, passados, presentes e futuros! O trabalho que você faz, fez ou fará é valioso e incrível, e nós realmente o apreciamos! + +Estamos sempre tentando pensar em maneiras de apoiar os mantenedores de pacotes. Fique à vontade para adicionar um comentário abaixo com qualquer sugestão que você possa ter. -If the balance feels off, consider your needs. It might be time to try and recruit co-maintainers or join a community of other developers, or even to find a new maintainer or retire the package. -For rOpenSci packages, we can help by advertising your package's need for help, so feel free to contact us. -Last but not least, we at rOpenSci would like to thank all package maintainers, past, present and future! The work you do, have done, or will do, is valuable and awesome, and we really appreciate it 🙏🏼 ! -We are always trying to think about ways to support package maintainers. Please feel free to add a comment below with any suggestions you might have.