In March we held a Community Call discussing the maintenance of R packages. This call included a starting presentation by Julia Silge followed by a discussion featuring panelists with a wide variety of backgrounds: Elin Waring, Erin Grand, Leonardo Collado-Torres and Scott Chamberlain.
The rOpenSci Package Maintenance Community Call was my (Janani’s) first Community Call and I loved it. For R/software-dev newbies, learning the right terminology/lingo/vocabulary is everything. It can take a few dozen blog posts and many hours of reading before beginners get to the ‘aha’ moment of ‘oh, these are the terms I need to use to search for what I’m thinking!’. As there are many online resources out there, the default expectation is that one can search for and learn almost everything provided one knows the right keywords. There’s nothing like hearing a lively technical banter of experts to pick up the vernacular that one can easily build upon. The first-hand tips and tricks, do’s and don’ts, personal anecdotes of what worked beautifully and what crashed terribly, offered by years of experience are yet unmatched in bringing newbies into speaking the community’s language. That is the precise gap filled in by the timely and helpful rOpenSci Package Maintenance Community Call!
During rOpenSci Community Calls, there is a shared document that allows anyone to add notes or questions during the discussion. I always take notes for my own use but quickly realized the benefit for all by taking collaborative notes. This live shared document helps everyone, including newbies, think through and formulate what they would like to say. It also gives people the option to participate without having to interrupt and speak up on the call (thus reducing the barrier for people, especially newcomers, to ask questions). The document also gives an opportunity for anyone in the community to share their expertise and add their perspective.
We felt that the rich content in the video and collaborative notes document from this call warranted a post that points readers to the material to ensure more people benefit from it. Here we’ve collated the questions and links to the various answers to facilitate look up.
Summarizing questions and answers
(Related: What should someone do if they want to start helping maintain one of your packages? First step?)
6. We’ve talked about a lot of different facets of package management. Which are the same vs. different for internal packages? (video)
What is the best practice for ensuring continued support for older R versions when dependencies of dependencies of dependencies keep upping the minimum version of R required? (document)
Athanasia Monika Mowinckel
Do any of you have a package that depends on software that is not from R, for instance another command line tool. I.e. your R package wraps system calls to the command line software and uses output from that in R. How do you improve user experience when the program needs environment variables R does not pick up with
I would also like to know how to incorporate a significant part of non-R scripts within the R package workflow – functions that use system/system2 calls, for instance! Are there any systematic ways and good examples that could point to this? (document)
If I want to start with fixing an issue/contributing to a well-documented package, what are essential parts that I should know before fixing? Should I learn package documentation and testing/awcontinuous integration and all other aspects of R packages… or are there parts that are necessary and others that are less urgent? Are there things that should be absolutely avoided? (things that can break the whole package)? (document)
What are some best practices for making big changes to a package? For example, changing the output of a function from a list to a tibble. Should this be a new function? Should there be an argument to get the old behavior back?
Warnings to users to update their code? (document)
You can also check out the list of resources related to this community call.
Excited for more?
We hope this has inspired you to join in with future community calls! What would YOU like to hear about on a future rOpenSci Community Call? Add your votes and ideas for topics and speakers by 1) browsing the issues in this public repository; 2) giving a or commenting on an issue; 3) opening a new issue if your idea doesn’t fit in any others.