rOpenSci - open tools for open science

From Peer Review to Mentorship: My rOpenSci Story

rOpenSci — Tue, 14 Jul 2026 00:00:00 +0000

Getting Involved with rOpenSci

I first came to rOpenSci in 2022, though at the time I barely knew what it was. I was getting a statistical package of mine ready to submit to the Journal of Statistical Software, and that is how I was pointed toward rOpenSci review: the journal directs authors to rOpenSci’s statistical software standards, so going through the review looked like a convenient step along the way. At the time, my focus was on polishing the software for the journal submission, not on rOpenSci itself.

What I did not expect was how much the process itself would change my perspective. Coming from an academic background, the open review on GitHub felt very different from the closed, anonymous process I was used to. It was rigorous without being adversarial. An editor and two reviewers carefully examined the package, and their feedback was constructive and grounded in rOpenSci’s well-defined standards and guidelines. The review improved the package, and it also gave me a greater appreciation for the collaborative approach behind open-source software review.

I was later invited to review a package myself. The experience gave me a different perspective on the review process. As a reviewer, I saw that the goal was not simply to determine whether a package met some standards or merits, but to help authors improve their software through constructive feedback. When applications opened for the Champions Program, mentoring felt like a natural next step. Having experienced rOpenSci as both a software author and a reviewer, it seemed like a meaningful way to contribute to the community.

Mentoring in the Champions Program

I was matched with Sunny Tseng as her mentor. Over the program, Sunny built bbsTaiwan, an R package that makes Taiwan’s Breeding Bird Survey data much easier to access and analyze. It was a real package solving a real problem for people who study Taiwan’s birds, which made it a pleasure to work on together.

Mostly, what I gave was time and attention. We worked through package scope, unit testing, version control, and the other practical aspects of building an R package. Many of our conversations were not about solving a particular technical problem, but about discussing trade-offs, identifying useful resources, and thinking through the next steps. Those conversations ended up being one of my favorite parts of the program.

What I valued most, though, was seeing how Sunny’s work was used after the project. It is easy to think of a package as code made available for others to use, but in this case it became a tool that supported people working with the same data. While visiting Taiwan, she also ran a session introducing it to members of that community. This reinforced my view that open-source software is not just code shared in public, but a way of bringing people together around shared work.

Looking Back

More than anything, my time with rOpenSci has left me with an appreciation for how thoughtfully it is run. Its initiatives, from peer review to mentorship, are organized with real care, and they are built to do more than improve software. They are designed to connect people, bring contributors together, and keep community at the center of open science.

Fifteen years in, what strikes me about rOpenSci is that it has always been more about people than about packages. What began as a convenient step on the way to a journal turned into one of the more rewarding parts of my work, and I have found value in each perspective I have seen as an author, a reviewer, and a mentor.

An API for Everything There Is to Know About Packages

rOpenSci — Wed, 08 Jul 2026 00:00:00 +0000

On R-Universe you can discover and learn everything there is to know about R packages. But did you know it does only provide a human-friendly website, but also programmatic access to all information through APIs! Thanks to those APIs you can list universes, list packages in an universe, get information on packages, and perform searches; all without any need for authentication.

The R-Universe APIs are both handy and reliable. You can build upon them, as both rOpenSci and community members have done. This post shows some examples of use cases with the R-Universe API.

Know which packages are yours

The toolbox for rOpenSci community management tasks, promoutils, calls an R-Universe API to list and get information on rOpenSci packages. This list of packages is in particular used in the function that outputs data on help-wanted issues.

Display packages developed at your organization

If your organization develops R packages, you can use its R-Universe as the source of truth for your package collection. For instance, the R-Universe of ggsegverse corresponds to, well, the ggsegverse. Therefore, on the ggsegverse website, the listing of packages is created by querying https://ggsegverse.r-universe.dev/api/packages, the endpoint for information on all packages in the universe.

Likewise, the docs page of ggsegverse relies on the R-Universe API to retrieve links to vignettes for each package.

Server-side or client-side API requests

The ggsegverse website performs client-side requests: it queries the R-Universe API when you open the webpage, through a JS script. You can also check this through the web developer tools:

The rendering of the nice package cards happens through another JS script that uses information such as the package’s title, description, number of stars, etc.

In contrast, for package listings on author and package pages, the rOpenSci website uses server-side requests: the API is called when Hugo renders our website. For instance, for the list of packages at the bottom of Jeroen Ooms’ author page, we query the R-Universe API link from our website configuration and filter the packages by GitHub login.

On a Quarto website, you could have a code chunk using R to query the R-Universe APIs, through the universe R package for instance.

In any case, if you use server-side requests, you need to re-render your website regularly to avoid your packages’ listing to get out-of-date. The nice thing about client-side requests is that the package lists will be always up-to-date!

Search Packages

With R-universe, you can search packages, not only through the web interface but also through an API.

The project The Wharehouse, that helps users find packages according to given keywords, uses R-universe as one its information sources.

Conclusion

In this post we provided some use cases of the R-Universe APIs. Try them out, or read the docs to get a sense of all the information that’s shared through the different endpoints. If you maintain some infrastructure that uses an R-Universe API, feel free to report a use case!

FOSS Tools for Lazy Editors

rOpenSci — Thu, 02 Jul 2026 00:00:00 +0000

I recently had the opportunity to learn what the term “Nerd Sniping” meant. Maëlle pointed out a conversation on the rOpenSci Slack about something called Vale, meant for text linting. I’d seen the comment, but honestly hadn’t really understood what it was all about until Maëlle asked if I thought it’d be useful for editing the blog…

…time passes…

About three days later, I’ve hardly finished any of the blog post reviews I was planning to do. I’ve been sucked down a rabbit hole of Vale setup, custom rules, and overrides.

It turns out that “Nerd Sniping” refers to the practice of throwing problems at nerds that distract them from what they were doing.

xkcd Nerd Sniping

That being said, it was a glorious hole to fall down! It was just too bad that Maëlle sniped me two more times by asking me about my spell check setup in Positron and then by asking if Panache would help with translations.

I was pretty slow at my editorial duties that week! But I did come out of the dive with a great editorial setup which will definitely save me time in future.

I’ve edited a lot of posts on the rOpenSci blog. I take pride in helping writers get their ideas across with clarity, while not losing their own style. I’m an opinionated editor, so I also try hard to ensure that writers understand when my suggestions are just my opinion, and when I think there are mistakes in style or content that really do need to be fixed. I am also fussy about the details, about being consistent with capitalizations, about keeping ideas logically ordered, and about making sure that readers without the same background might still understand the gist of the post¹.

As such, my post reviews can get a bit lengthy and it’s not unreasonable for me to have 20-30 comments on a standard post. That’s not too problematic, but if I had to complain it might be about the technical edits, like fixing the capitalization of ‘rOpenSci’², ensuring headings are in sentence case, and that links to ropensci.org pages are relative. These aren’t complicated fixes, but if you have to remember to keep an eye out for them, and then create a GitHub PR review suggestion for each fix, it can become a tad tedious.

Maëlle’s timely sniping helped me finalize my collection of tools to help streamline editorial tasks.

Spell checking with cSpell
Linting³ with Vale
Formatting with Panache
Creating GitHub PR suggestions with GitHub Pull Requests

All of these tools can be installed and used in different ways. They are also powerful with many different possible customizations and configurations. Here, I’ll share with you how I use these tools as extensions in Positron to help make it easier to write and edit posts for the rOpenSci blog. Hopefully this inspires you to explore how you might set them up to support your workflows! Further, if you’re interested in setting up your own tools, perhaps you want to check out this blog post on “All the Ways to Programmatically Edit or Parse R Markdown / Quarto Documents”.

General setup

For each tool, you’ll want to install the Positron extension, and then set up your configuration. Configurations can usually be specified at three different levels:

User: Your system-wide setup which is how you want things to work in general across projects. User config files are generally stored somewhere in your home directory.
Project: Project-wide setup which overrides your user setup if the project does things differently. These config files are stored in the project directly (like roweb3, for the rOpenSci blog).
File: File or file section setup which works at a very local scale. Usually this configuration is indicated by in-file comments.

More specifically here are (some) of the locations/names for configuration files and links to their documentation sections for more details.

Level	cSpell	Vale	Panache
User	Positron settings	`.vale.ini` in any parent dir. or global config	`~/.config/panache/config.toml`
Project	`.cspell.json`	`.vale.ini`	`.panache.toml`
File	Inline Comments	Inline Comments	Inline Comments

This means you can have different rules for different projects, and override them as needed. In the following examples, I’ll show you how I do this for posts on the rOpenSci blog.

Code Spell Checker (cSpell)

First is my spell checker, which probably doesn’t need much explanation. However, it’s nice to use a spell checker which also works on code. I use the Code Spell Checker (cSpell) extension by Street Side Software and installed the languages extensions individually:

Canadian English⁴ - Code Spell Checker
French - Code Spell Checker
Portuguese - Code Spell Checker
Spanish - Code Spell Checker

Alternatively, you could also install the cSpell Bundled Dictionaries instead.

To configure this extension, I added two types of files: a project-level configuration file, and two dictionaries of words to consider ‘correct’.

The project level configuration file, .cspell.json, lists languages to use for different files (to ensure index.es.md files go through the Spanish spellchecker, while index.pt.md files go through the Portuguese spellchecker, etc.). It also includes a list of globs for file paths we can ignore (I’m really not interested in spelling mistakes in the .git folder), as well as pointing to dictionaries.

These dictionaries are initially created by functions from my promoutils package, an R package for all my rOpenSci community workflows. wordlist_create() creates a wordlist based on rOpenSci packages and author names, so they don’t trigger the spell check if they aren’t recognized. wordlist_update() updates this list with new names as needed.

We keep these dictionaries in a .wordlists folder. Names are stored in the .wordlists/names.txt file, and we also have a .wordlists/words.txt file which stores words which are considered correct in the rOpenSci context (like ‘usecases’).

I should also note that I have a personal list of user words stored in my Positron user settings which lists words (like my name!) which I want to be considered correct across all projects.

When writing posts, we can also override the language settings within a post using a special comment. For example if we want to use English and Portuguese for a post we could add <--- cSpell: language en,pt--> to the document.

We can also include post-specific words to ignore, which is handy for acronyms. For example, if we wanted to ignore the acronym CSCW we could use  at the top of a post.

Spell check issues pop up as a warning in my text window, or as a list under “Spell Checker Issues By File” my lower window pane so I can review them, add them to word lists, or just mentally ignore them.

Vale

For linting text (checking the style and meaning of the words) I use the Vale VSCode extension by chrischinchilla⁵. Vale helps me check that the Blog Style rules are respected, and gives suggestions for alternative word choices to avoid common mistakes (such as words or expressions which might be derogatory).

To setup Vale I created a project-specific Vale configuration file .vale.ini⁶ in the roweb3 repository. I keep my personal .vale.ini file in a higher level folder that holds all my R projects. In addition to the Vale configuration file, I also created a Vale styles folder in roweb3/.vale-styles. This is where Vale rules are installed if we use predefined rules, and where I can put rOpenSci-specific rules for the blog. The first time you use Vale you’ll want to run vale sync in the terminal to install the standard, non-custom, rules. I .gitignore all rules which are installed, but track and push custom rules.

Vale is where I’ve made the most customizations, especially with the rOpenSci Blog.

I’ve added a specific Blog vocab list to ensure proper capitalization of rOpenSci projects and (not to mention “rOpenSci” 😉)
I’ve turned off a lot of specific rules which are a bit too aggressive for a blog which allows people to write casually and informally as they like (including using words like “very” 😄).
I’ve created custom rules to modify existing rules ⁷
I’ve created custom rules to enforce our style guide, like using Title Case for blog post titles⁸, sentence case for subheadings, and using relative links for ropensci.org pages.

This is just the start! I imagine the more I use these rules the more fine tuning I’ll do.

Vale problems are classified as messages, warnings, or errors, and are highlighted in the text window as a quick fix and listed in the Problems pane in my lower window.

I should also note that for all the rules I’ve disabled, there are a lot of opinionated rules left. We keep them as prompts to think about our writing, not because we must follow them!

Vale’s write-good rule doesn’t want me to start a sentence with ‘There is’, but I’m going to anyway!

Panache

For formatting text, I use the Panache extension by jolars to format the (R)markdown files for the blog. This is probably the smallest amount of setup, as all we need is a minimal .panache.toml configuration file in the roweb3 repository. However, this file instructs Panache to do one super awesome thing for us, especially for translations of multilingual blog posts:

[format]
wrap = "sentence"

If you set up Positron to format on save, Panache automatically wraps text by sentence every time you save the file. This means that when a blog post is sent for a first pass translation using babeldown, the translation comes back pretty good. Alternatively, if the line breaks are in the middle of a sentence, the translation can become garbled as lines are treated as disjointed sections of text.

For my other work, I use wrap = "reflow", set in my user configuration file in ~/.config/panache/config.toml.

GitHub Pull Requests

Finally, once I’ve got all the fiddly edits on a post’s (R)md file ready to go, I use the GitHub Pull Requests extension to convert these edits to GitHub PR review suggestions. This is really handy if you find yourself making many small suggested changes to GitHub PRs.

To review blog posts, I fetch the PR with usethis::pr_fetch(), and then open the blog post (R)md file in Positron side by side with the html preview of the post in my web browser.

Then I review the html preview and make the edits directly in the (R)md file. When I’m done, I right click on the edited file name in the Source Control > Changes and select Create Pull Request Suggestions.

This converts my edits to GitHub PR review suggestions which I can then review in Positron, or as I prefer, in a web browser (and fix weird ones, such as suggestions which delete part of a section in one edit but add it back in the next; it’s not always a perfect process). Once all the suggestions are converted, the extension asks me if I want to revert my changes (which I usually do).

A note of caution, I find this tool a bit confusing to use on a PR that has a lot of comments already. The comments it makes are sometimes hidden or split in odd ways and it’s easy to accidentally create duplicates. In these situations it’s sometimes easier just to make the suggestions in a browser as you might normally.

Why so many tools?

Each of these tools provides me a specific solution to a problem. There is some overlap among them; Vale could do spell checks, and Panache could do linting. However, I find that by using the tools separately I can achieve an especially detailed and customized setup that works really well with the rOpenSci blog in particular, and with my work in general.

By including the configuration files in the roweb3 repository, people who also use these tools will automatically use the configurations we’ve setup for the rOpenSci blog when they write a post. We also plan to add instructions for how to use these tools to the Blog Guide. This should give blog writers the option of using these tools if they would like to.

However, even if other writers don’t use these tools, it’s still very useful for me to see a list of potential problems to double check at the end of my review without having to remember to check for them manually. It means I can focus more on the review of the content rather than worry about whether it’s Ropensci or rOpenSci 😄

Don’t judge this post by these ideals, I said I’m a opinionated editor, writing is completely different 😉. ↩︎
It’s rOpenSci. Not Ropensci, not RopenSci and not ropenSci. ↩︎
“Linting” with respect to text or prose means checking the style and meaning of the words. ↩︎
I’m Canadian so generally follow Canadian spelling (a mix of British and American for those of you new to the complex world of English spelling differences). At rOpenSci, we generally just ask an author to pick one and stick to it. ↩︎
There is also Vale by errata-ai, but this extension has been deprecated in favour of Vale VSCode. ↩︎
If you get an error on startup, you may need to tell Vale where this is explicitly by modifying Projects’ settings.json file to include "vale.valeCLI.config": ".vale.ini" ↩︎
For example, alex worries that the word “Mexican” might be used in a racist manner, but at rOpenSci, it’s stated with pride and I don’t want Vale to flag our community members for mentioning their nationality 😅 ↩︎
But awesomely, we can enforce this rule for English, but not Spanish posts! ↩︎

rOpenSci News Digest, June 2026

rOpenSci — Tue, 30 Jun 2026 00:00:00 +0000

Dear rOpenSci friends, it’s time for our monthly news roundup! You can read this post on our blog. Now let’s dive into the activity at and around rOpenSci!

rOpenSci HQ

Champions Program update

We have two concurrent cohorts, both in Spanish.

The 2025–2026 cohort is nearing the end of its participation in the program, so we are organizing the closing meeting and the overall evaluation.

The 2026–2027 cohort is continuing their training activities, meeting with their mentors, and starting to work on their packages, and they have been formally introduced on our blog! Read all about the 11 new Champions.

New editors Ronny Hernandez Mora, Joel Nitta, and Nick Tierney

We’re thrilled to introduce new editors Ronny Hernandez Mora, Joel Nitta, and Nick Tierney. An official welcome and thank you to all three!

A new guide: Organizing Events for First-time Contributors

Steffi LaZerte and Yanina Bellini Saibene released a fantastic new rOpenSci guide! Learn how to organize events for first-time contributors such as mini-hackathons and mini-translathons. Read more in the release announcement.

R-Universe updates

“Five recent R-Universe features you might have missed”: A clickbait title for a blog post you don’t want to miss! 😉 Jeroen Ooms describes five recent additions to the R-Universe platform:

Social media cards that actually look good
PACKAGES.rds support (or: implementing R internals in JavaScript)
Fancy sort/filter bars in the WebUI
For the impatient: trigger a sync manually
Making check results easier to find and share

In other news, R-universe user Tom Palmer also wrote about five things: “Five tips for managing your R-universe 🚀”. You won’t believe the fifth one. 😉

Yanina Joins the 2026 Sovereign Tech Fellowship

We’re excited to share that our Community Manager, Yanina Bellini Saibene, has been selected as a 2026 Sovereign Tech Fellow. During the fellowship, she will focus on making open source more accessible through improved contribution guidance, newcomer-focused mini-hackathons, multilingual training resources, and more sustainable localization practices across communities in the R ecosystem. These efforts will build on and extend rOpenSci’s work in community building, mentorship, and open science.

Quinceañera: celebrating 15 years together

In June, we held two community events and a co-working session to mark rOpenSci’s 15th anniversary. Across all three sessions, people shared memories of their first contribution, discussed ideas for the next 15 years, and reminded us of how genuinely welcoming rOpenSci and it’s community are. There’s more to come :-) Keep an eye out for what we have planned for the rest of the year.

Software Peer-Review updates

Community member Athanasia Mo Mowinckel has started a new AI agent “skills” repo at ropensci-review-tools/ropensci-skills. The repo holds a variety of “skills”, which are human-readable markdown files, for AI agents to assist in preparing software for peer-review. Anybody thinking about using AI systems to prepare software for peer-review is encouraged to try out these experimental skills, and to help us improve them for others by opening issues or pull requests in the GitHub repo.

Our recent updates to the goodpractice package have also been enhanced with an all-new AI “skill”. This skill instructs agents to edit and improve your package’s code to comply with the full suite of goodpractice checks. You can try it out with the package’s new use_skill_gp() function.

Coworking

Read all about coworking!

Tuesday July 7nd 2026, 09:00 Americas Pacific (16:00 UTC) “Debugging in R”, with Yanina Bellini Saibene and cohost Shannon Pileggi.
- Read up on debugging in R.
- Meet community host, Shannon Pileggi, and discuss tips and tricks for debugging in R.
Tuesday August 4th, 09:00 Australia Western (01:00 UTC) “Vale and Text Linting”, with Steffi LaZerte and cohost Jonathan Carroll.
- Read up on text linting.
- Setup a linting framework for your projects.
- Meet co-host, Jonathan Carroll, and discuss Vale and text linting.
Tuesday September 1st, 14:00 Europe Central (12:00 UTC) “Getting to Know SORTEE”, with Steffi LaZerte and cohost Ed Ivimey-Cook.
- Visit SORTEE (Society for Open, Reliable, and Transparent Ecology and Evolutionary Biology).
- Meet co-host, Ed Ivimey-Cook, and learn more about SORTEE and how you might get involved.

And remember, you can always cowork independently on work related to R, work on packages that tend to be neglected, or work on what ever you need to get done!

Software 📦

The following two packages recently became a part of our software suite:

pvEBayes, developed by Yihao Tan together with Marianthi Markatou, Saptarshi Chakraborty, and Raktim Mukhopadhyay: A suite of empirical Bayes methods to use in pharmacovigilance. Contains various model fitting and post-processing functions. For more details see Tan et al. (2025) https://doi.org/10.1002/sim.70195, https://doi.org/10.48550/arXiv.2512.01057; Koenker and Mizera (2014) https://doi.org/10.1080/01621459.2013.869224; Efron (2016) https://doi.org/10.1093/biomet/asv068. It has been reviewed by Kathryn Doering and Collin Cademartori.
nycOpenData, developed by Christian Martinez: Provides a unified set of helper functions to access datasets from the NYC Open Data platform https://opendata.cityofnewyork.us/. Functions return results as tidy tibbles and support optional filtering, sorting, and row limits via the Socrata API. The package includes endpoints for 311 service requests, DOB job applications, juvenile justice metrics, school safety, environmental data, event permitting, and additional citywide datasets. It has been reviewed by Haolin Dong and Michael Pascale.

Discover more packages, read more about Software Peer Review.

New versions

The following seventeen packages have had an update since the last newsletter: weathercan (v1.0.0), occCite (v0.6.2), lightr (v2.0.0), gutenbergr (v0.5.2), slopes (v2.0.0), qualtRics (v3.3.0), srr (v1.0.0), goodpractice (v1.1), pkgmatch (v0.5.4), pkgstats (v0.2.3), cffr (v1.4.1), dfms (v1.0.1), osmdata (v0.4.0), aRxiv (0.20), Athlytics (v1.0.6), ReLTER (3.1.1), and read.abares (v3.0.0).

The writexl package has a new maintainer, Bill Denney. NLMR is now maintained by Jakub Nowosad.

Software Peer Review

There are eighteen recently closed and active submissions and 4 submissions on hold. Issues are at different stages:

Four at ‘6/approved’:
- pvEBayes, Empirical Bayes Methods for Pharmacovigilance. Submitted by Yihao Tan. (Stats).
- nycOpenData, Convenient Access to NYC Open Data API Endpoints. Submitted by Christian Martinez.
- ernest, A Toolkit for Nested Sampling. Submitted by Kyle Dewsnap. (Stats).
- pkgmatch, Find R Packages Matching Either Descriptions or Other R Packages. Submitted by mark padgham.
Two at ‘5/awaiting-reviewer(s)-response’:
- lakefetch, Calculate Fetch and Wave Exposure for Lake Sampling Points. Submitted by jeremylfarrell.
- priorsense, Prior Diagnostics and Sensitivity Analysis. Submitted by Noa Kallioinen. (Stats).
Five at ‘4/review(s)-in-awaiting-changes’:
- RAQSAPI, A Simple Interface to the US EPA Air Quality System Data Mart API. Submitted by mccroweyclinton-EPA.
- RAMEN, RAMEN: Regional Association of Methylome variability with the Exposome and geNome. Submitted by Erick Navarro-Delgado.
- logolink, An Interface for Running NetLogo Simulations. Submitted by Daniel Vartanian.
- rcrisp, Automate the Delineation of Urban River Spaces. Submitted by Claudiu Forgaci. (Stats).
- galamm, Generalized Additive Latent and Mixed Models. Submitted by Øystein Sørensen. (Stats).
Two at ‘3/reviewer(s)-assigned’:
- ciecl, International Classification of Diseases ICD-10/ICD-11 for Chile. Submitted by Rodolfo Tasso.
- EpiStrainDynamics, Infer temporal trends of multiple pathogens. Submitted by Saras Windecker. (Stats).
Two at ‘2/seeking-reviewer(s)’:
- fcmconfr, Fuzzy Cognitive Map Analysis in R. Submitted by benroston. (Stats).
- coevolve, Fit Bayesian Generalized Dynamic Phylogenetic Models using Stan. Submitted by Scott Claessens. (Stats).
Three at ‘1/editor-checks’:
- grumpy, Read NumPy .npy and .npz Files. Submitted by Hugo Gruson.
- metasurvey, Reproducible Survey Data Processing with Step Pipelines. Submitted by Mauro Loprete.
- LBDiscoverAnalysis, Co-occurrence Discovery Models and Visualization for Biomedical LBD. Submitted by Chao Liu.

Find out more about Software Peer Review and how to get involved.

On the blog

Software Review

Ronny Hernandez Mora, Joel Nitta, and Nick Tierney Join rOpenSci Software Peer Review Editorial Team by Ronny Hernandez Mora, Joel Nitta, Nicholas Tierney, and Yanina Bellini Saibene. Introducing three new editors for rOpenSci software peer review.
Celebrating Our Maintainers during Maintainers Month by Yanina Bellini Saibene. A Look Back at our Maintainer Month 2026 social media campaign.
Our goodpractice Package Has New Superpowers by Mark Padgham and Athanasia Mo Mowinckel. We have worked hard over the past few months on major upgrades to our goodpractice package. Checks are now grouped into categories, making it easier to control which checks are run. The biggest change has been adding over 100 new checks, from new lints to many new CRAN checks.
A New Guide: Organizing Events for First-time Contributors by Steffi LaZerte and Yanina Bellini Saibene. We introduce our Guide book for organizing events to support first-time contributors to FOSS.
Five recent R-universe features you might have missed by Jeroen Ooms. In this technote we look at a few recent additions that make R-universe a little nicer, faster, or more convenient to use.
Eleven Latin American Voices for Open Science: The New Cohort of Champions rOpenSci 2026 by Bastián Olea Herrera, Denisse Fierro Arcos, Durga Valentina Linares Herrera, Evelia Lorena Coss Navarrete, Gladys Choque Ulloa, José Daniel Conejeros, Linda Cabrera Orellana, María Florencia Tames, Marina Cecilia Cock, Patricia A. Loto, Estefania Torrejón, and Yanina Bellini Saibene. Introducing 11 new rOpenSci Champions. Other languages: Once voces latinoamericanas para la ciencia abierta: la nueva cohorte de Campeon(a|e)s rOpenSci 2026 (es).

Calls for contributions

Calls for maintainers

If you’re interested in maintaining any of the R packages below, you might enjoy reading our blog post What Does It Mean to Maintain a Package?.

charlatan, create fake data in R. Issue for volunteering.
hddtools, Tools to discover hydrological data, accessing catalogues and databases from various data providers. Issue for volunteering.

Calls for contributions

Refer to our help wanted page – before opening a PR, we recommend asking in the issue whether help is still needed.

Package development corner

Some useful information for R package developers. 👀

goodpractice’s new features and behind-the-scene notes

Software Review Lead Mark Padgham and long-time community member Athanasia Mo Mowinckel have written a blog post particularly relevant to package developers for two reasons:

Learn how goodpractice, which helps make your package better, has improved.
Read how Mark and Mo collaborated, including their use of LLMs in the development process.

Dumb Ways for an Open Source Project to Die

If you’re interested in open-source software projects’ survivability, you’ll enjoy this write-up by Andrew Nesbitt shared by Yanina Bellini Saibene.

Refactoring with Jarl: unused functions and more

Hannah Frick and Maëlle Salmon wrote “Refactoring with Jarl: a coffee chat” on the R-hub blog.

A strategy for recovering data on request interruption

Gábor Csárdi summarized recent changes to the gh package. Especially interesting is his strategy for interruptions: the user starts a long query then interrupts the process… how to not lose the data that’s already been received? The solution is to make it accessible through rlang::last_error(). More details in the post.

curl summer of bliss

The curl project announced that it will not accept any vulnerability report during the month of July this year. This is both the opportunity for maintainers to take a break, and to advertise paid curl support, in which there will be no interruption of service.

To conventionally commit or not

Sumner Evans wrote an interesting post criticizing the conventional commits convention (starting commits with e.g. fix: for bug fixes, feat: for new features, etc).

More than .gitignore

Nelson Figueroa wrote a useful overview of the different ways to make Git ignore some files.

How to work with LLMs without losing your skills

Vicki Boykis wrote an insightful post “We should be more tired than the model” including pratical tips such as “Starting to use the agent only after I’ve spent 20 minutes on the problem” or “Discussing an agent’s proposed implementation with another person instead”.

Last words

Thanks for reading! If you want to get involved with rOpenSci, check out our Contributing Guide. This guide will help direct you to the right place, whether you want to make code contributions, non-code contributions, or contribute in other ways such as through sharing use cases. You can also support our work through donations.

If you haven’t subscribed to our newsletter yet, you can do so though our signup form. Until it’s time for our next newsletter, you can keep in touch with us through our website, Mastodon, or LinkedIn. See you soon!

Celebrating Our Maintainers during Maintainers Month

rOpenSci — Fri, 19 Jun 2026 00:00:00 +0000

May was Open Source Software Maintainer Month. Behind every R package there is at least one person who responds to issues, reviews pull requests, keeps up with dependency changes, and makes sure everything still works. During Maintainer Month we wanted to celebrate rOpenSci’s package maintainer community.

The social media campaign

One of our commitments to our community is to amplify the people who make it work. Social media is one of the ways we do that, so we thought Maintainer Month would be a great opportunity to highlight the people behind the packages through a social media campaign.

To run this campaign, we first needed permission from our maintainers to feature them. In our annual maintainer survey, we asked whether they would be interested in being featured in a public spotlight, and many said yes.

We also reached out to current and past Champions from our Champions Program, which trains and supports R developers from historically underrepresented groups in the open science community.

The result was a month-long series of spotlights: one maintainer at a time, each card sharing who they are, where they come from, and what they maintain.

This campaign brought together 37 maintainers from 15 countries, maintaining more than 50 packages that together serve thousands of researchers and data practitioners around the world.

The diversity of this group reflects the diversity of the rOpenSci community: archaeologists, bioinformaticians, ecologists, economists, statisticians, sociologists, professors, PhD students, engineers and educators.

We created 39 posts on our accounts on LinkedIn and Mastodon, which is bridge to BlueSky. All the posts were shared by other people and organizations and received comments from grateful users.

Meet all 37 maintainers

Here is the full list of maintainers we celebrated in May.

Alex Koiter 🇨🇦 maintains {mbquartR}, for working with Manitoba’s quarter-section land survey system in watershed and land management research.
Andrea Gomez Vargas 🇨🇴🇦🇷 maintains {ARcenso}, for accessing and analyzing Argentina’s national census data in R. Champions project.
Austin Koontz 🇺🇸 maintains {SymbiotaR2}, an R interface to the Symbiota platform for accessing and managing biodiversity occurrence data from natural history collections.
Bilikisu Wunmi Olatunji 🇳🇬 maintains {chartkickR}, an R wrapper for the Chartkick JavaScript library that makes it easy to create beautiful interactive charts and visualizations from R. Champions project.
Carolina Pradier 🇦🇷🇨🇦 maintains {eph}, for downloading and analyzing microdata from Argentina’s Permanent Household Survey, supporting labour and socioeconomic research. Champions project.
Daniel Vartanian 🇧🇷 maintains {mctq}, for processing data from the Munich Chronotype Questionnaire in sleep and chronobiology research.
Erick Navarro Delgado 🇨🇦🇲🇽 maintains {RAMEN}, for identifying associations between environmental exposures and molecular outcomes in multi-omics research. Champions project.
Erika Siregar 🇮🇩🇬🇧 maintains {rplaywright}, an R interface to Microsoft Playwright for browser automation and web testing. Champions project.
Ezekiel Adebayo Ogundepo 🇳🇬 maintains {bulkreadr}, for simplifying the bulk import of multiple files into R across a range of formats. Champions project.
Francesca Palmeira 🇧🇷 maintains {pcir}, for modeling species interaction data and food web structures in conservation research. Champions project.
Guadalupe Pascal 🇦🇷 maintains {matildaNLP}, a package with a specialized corpus of Spanish texts from the Matilda initiative to support research on gender-aware language processing and policy. Champions project.
Haydée Svab 🇧🇷 maintains {odbr}, for accessing open data urban mobility from a series of cities in Brazil. Champions project.
Jeroen Ooms 🇳🇱 maintains {magick}, {pdftools}, and {gert}, packages for image processing, PDF manipulation, and Git operations in R.
Jonathan Keane maintains {dittodb}, which makes testing database-backed code easy by recording and replaying real database interactions so tests can run without a live connection.
Julia Silge 🇺🇸 maintains {qualtRics}, for importing survey data from the Qualtrics platform directly into R.
Karl Broman 🇺🇸 maintains {chromer} and {aRxiv}, for accessing chromosome data and the arXiv preprint server.
Maëlle Salmon 🇫🇷 maintains {saperlipopette}, {babelquarto}, and {babeldown}, tools for learn how to use git, create multilingual Quarto documents, and support translations workflows.
Marcelo S. Perlin 🇧🇷 maintains {yfR}, for importing financial data from Yahoo Finance into R.
Marcos Prunello 🇦🇷 maintains {karel}, a package that brings the Karel the Robot programming environment to R, designed to teach programming concepts and computational thinking to beginners. Champions project.
Mark Padgham 🇩🇪 maintains {pkgcheck}, which automates software checks for packages submitted to rOpenSci peer review.
Mauro Loprete 🇺🇾 maintains {metasurvey}, for processing and analyzing household survey microdata using a metadata-driven approach. Champions project.
Micha Silver 🇮🇱 maintains {rOPTRAM}, implementing the OPtical TRApezoid Model for estimating soil moisture from satellite imagery.
Moritz Hennicke 🇧🇪 maintains {nuts}, for working with the EU’s Nomenclature of Territorial Units for Statistics, useful in regional economics and policy research.
Pao Corrales 🇦🇷🇦🇺 maintains {agroclimatico}, for calculating agroclimatic indices and bioclimatic variables for agricultural and environmental research. Champions project.
Peter Desmet 🇧🇪 maintains {frictionless}, for working with open data standards and publishing datasets.
Philippe Massicotte 🇨🇦 maintains {rnaturalearth}, {rnaturalearthdata}, and {gitignore}, for working with natural earth map data and project utilities.
Sam Albers 🇨🇦 maintains {tidyhydat}, for accessing Canadian hydrometric data in a tidy format.
Steffi Lazerte 🇨🇦 maintains {weathercan}, for downloading Canadian weather data directly from Environment and Climate Change Canada.
Tad Dallas 🇺🇸 maintains {helminthR}, for accessing the London Natural History Museum’s host-parasite database.
Ronald M. Visser 🇳🇱 maintains {dendroNetwork}, for creating and analyzing networks in dendrochronological research, combining archaeology and data science.
Sehrish Kanwal 🇦🇺 maintains {RNAsum}, for summarising and visualising RNA-seq data analysis results in clinical cancer genomics workflows. Champions project.
Victor Ordu 🇳🇬🇺🇸 maintains {naijR}, a package of tools and utilities for working with data and maps about Nigeria. Champions project.
Will Gearty 🇺🇸 maintains {rredlist}, for accessing IUCN Red List data on threatened species.
Will Landau 🇺🇸 maintains {targets}, a pipeline toolkit that makes data analysis in R faster and fully reproducible by tracking dependencies and only re-running what has changed.
Will Pearse 🇬🇧 maintains {suppdata}, for downloading supplementary data files directly from published scientific articles across major journals.
Yi-Chin Sunny Tseng 🇨🇦🇹🇼 maintains {bbsTaiwan}, for accessing and analyzing data from Taiwan’s Breeding Bird Survey. Champions project.
Zhian Kamvar 🇺🇸 maintains {tinkr}, for reading and writing Markdown documents in R as XML.

Thank you Maintainers!

Maintaining open source software is an act of generosity. It takes time that could be spent elsewhere, and it often goes unacknowledged. Every bug fix, every answered issue, every new feature and update is a small gift to the people who depend on that package.

We are grateful to all the rOpenSci maintainers. If you use any of these packages, consider saying thank you. You can also let us know how you use these packages by sharing your use case, that we will feature in our website.

Want to learn more? Explore the rOpenSci’s packages in our website and check all the other packages universes in R-Universe.