10 things I hate about you[R] packages 😉

[stefaniebutland]

Topic

10 things I hate about you[R] packages a.k.a. Good practices for R package development

Who is the audience?

Anyone from people curious about making their first R package to experienced developers

Why is this important?

Lots of people want to know about good practices for R package development and LOTS of people have experience and opinions.

What should be covered?

We're being ambitious and considering selecting/inviting people to record 3-5 mins on their R package pet peeves and then asking that as many of those folks as possible join the community call Q & A.

Suggested speakers or contributors

Reply to tell us whose pet peeves and tips you want to hear!

Resources you would recommend to the audience

Become an R package developer, by @maelle

[maelle]

Some thoughts

• Great topic and having different voices will make it entertaining.
• Should the title be phrased positively instead? 10 ways to make me like your R package.
• READMEs #11 is a pet peeve/tip I would like to see featured. If needs be I can be in charge of this segment, @annakrystalli would you like talking about good READMEs with me? 😉
• Also related to docs, making info easy to find (pkgdown reference index organization, repeating yourself with re-usable Rmd fragments in manual pages, README, vignettes). For this and the former point a video showing how a package looks to an outsider might help (fake package maybe).
• Examples of the most helpful hints in case of errors.
• Recently @cderv added a default value of the first argument of bookdown::render_book(), small impactful change (in an already awesome package). So a tip about having good default values?
• Something about making your package work with the wider ecosystem, thinking of the spatial packages Recommend sf over sp? ropensci/software-review-meta#47

[maelle]

Another topic, changing stuff in your package cf https://devguide.ropensci.org/evolution.html by @sckott ropensci/dev_guide#287 -- how to best inform and guide your users.

[annakrystalli]

#11 is a pet peeve/tip I would like to see featured. If needs be I can be in charge of this segment, @annakrystalli would you like talking about good READMEs with me? 😉

Sure thing! Count me in 😉

[stefaniebutland]

Great to hear @annakrystalli! For now it feels like #11 will be covered in "Set up your package to get the most out of your community #21" so I'll tag you over there and we'll see how they develop.

[monicagerber]

I love the framing as pet peeves and the topic title but also agree with Maëlle that it should be framed positively. Maybe a compromise would be to keep the title, but one of the pet peeves is assuming that your way is better than others, or a condescending code review.

[llrs]

Maybe you can find this post I wrote some years ago interesting: https://b101nfo.blogspot.com/2018/11/coding-ecosistem.html It covers not just the package but the setup of your coding environment.

[maelle]

For the resources, this great slidedeck by @apreshill about crafting kind tools https://alison.netlify.app/ares-kind-tools/#1

[yabellini]

We have updated tips and good resources on this topic for the Champions Program (your training material @maelle :-)).

[yabellini]

Some options for the title of this comm call:

• 10 features to love in R packages
• 10 ways to Improve your R package
• 10 tips & tricks to develop your R package
• 10 R package development tips you never thought about.

Others?

[maelle]

We could even remove the number that makes it look like a clickbait. "The best package development tips from the rOpenSci community" or so.