rOpenSci - open tools for open science

reviser: Analyzing Real-Time Data Revisions in R

rOpenSci — Mon, 13 Apr 2026 00:00:00 +0000

Economic data are rarely static. Gross domestic product (GDP), inflation, employment, and other official statistics arrive as early estimates, then get revised as new source data arrive, seasonal adjustment is updated, or benchmarking changes are applied. Those revisions matter because they can change the narrative around turning points, policy mistakes, and forecast performance.

reviser is an R package by Marc Burri and Philipp Wegmüller for working with these vintage datasets directly. A vintage dataset records multiple published versions of the same time series, so you can compare what was known at each release date with what was reported later. reviser gives you a consistent workflow to:

reshape release vintages between wide and tidy formats;
extract revisions relative to earlier or final releases;
summarize bias, dispersion, and serial dependence in revisions;
identify the first release that is statistically close to the eventual benchmark;
nowcast future revisions with state-space models.

The package is aimed at users who already work with real-time macroeconomic data and want tools that go beyond plotting revision triangles by hand. One design goal is to keep that workflow in pure R.

reviser was reviewed through rOpenSci statistical software peer review. Many thanks to reviewers Alex Gibberd, and Tanguy Barthelemy, and to editor Rebecca Killick, for feedback that improved the package.

Why revision analysis deserves its own workflow

Revisions are not just measurement noise. They encode how information enters the data-production process.

Some revisions reflect genuinely new information.
Others reflect noise that could, in principle, have been reduced earlier.
Still others come from methodological changes or benchmark updates.

These distinctions matter if you are evaluating early data releases, building nowcasts, or asking whether first releases are already efficient summaries of the available information.

The reviser vignettes organize this workflow into three layers:

Structure vintages consistently.
Measure and test revision properties.
Model the revision process when you want to predict future changes.

A compact example with GDP vintages

The first step is to reshape the data into a tidy vintage format, where each row corresponds to an observed value, the date it refers to, and the publication date of that estimate.

The package ships with a GDP example dataset in long vintage format. Suppose we want to focus on U.S. GDP growth, visualize how estimates moved during the 2008-09 global financial crisis, and then ask whether early releases were systematically biased relative to a later benchmark.

library(reviser)
library(dplyr)
library(tsbox)

gdp_us <- gdp |>
  filter(id == "US") |>
  tsbox::ts_pc() |>
  tsbox::ts_span(start = "1980-01-01")

gdp_wide <- vintages_wide(gdp_us)
gdp_long <- vintages_long(gdp_wide, keep_na = FALSE)

With the vintages in tidy form, we can plot how the published path changed over time. The y-axis in the figure reports quarter-on-quarter GDP growth rates.

plot_vintages(
  gdp_long |>
    filter(
      pub_date >= as.Date("2009-01-01"),
      pub_date < as.Date("2010-01-01"),
      time > as.Date("2008-01-01"),
      time < as.Date("2010-01-01")
    ),
  type = "line",
  title = "Revisions of GDP during the 2008-09 global financial crisis",
  ylab = "Quarter-on-quarter GDP growth rate"
)

GDP growth vintages for the United States during the 2008-09 global financial crisis.

During volatile periods, the vintage paths can diverge enough that the story told by the first release is noticeably different from the story told a year later.

Once the data are in tidy vintage form, you can compare a set of early releases to a later benchmark release.

final_release <- get_nth_release(gdp_long, n = 10)
early_releases <- get_nth_release(gdp_long, n = 0:6)

summary_tbl <- get_revision_analysis(early_releases, final_release)

Warning: Both 'release' and 'pub_date' columns are present in 'df.
      The 'release' column will be used for grouping.

summary_tbl |>
  select(id, release, `Bias (mean)`, `Bias (robust p-value)`, `Noise/Signal`)


=== Revision Analysis Summary ===

# A tibble: 7 × 5
  id    release   `Bias (mean)` `Bias (robust p-value)` `Noise/Signal`
  <chr> <chr>             <dbl>                   <dbl>          <dbl>
1 US    release_0        -0.014                   0.52           0.22 
2 US    release_1        -0.015                   0.425          0.202
3 US    release_2        -0.013                   0.507          0.205
4 US    release_3        -0.003                   0.851          0.194
5 US    release_4        -0.014                   0.326          0.157
6 US    release_5        -0.021                   0.181          0.152
7 US    release_6        -0.018                   0.202          0.13 

=== Interpretation ===

id=US, release=release_0:
  • No significant bias detected (p = 0.52 )
  • Moderate revision volatility (Noise/Signal = 0.22 )

id=US, release=release_1:
  • No significant bias detected (p = 0.425 )
  • Moderate revision volatility (Noise/Signal = 0.202 )

id=US, release=release_2:
  • No significant bias detected (p = 0.507 )
  • Moderate revision volatility (Noise/Signal = 0.205 )

id=US, release=release_3:
  • No significant bias detected (p = 0.851 )
  • Moderate revision volatility (Noise/Signal = 0.194 )

id=US, release=release_4:
  • No significant bias detected (p = 0.326 )
  • Moderate revision volatility (Noise/Signal = 0.157 )

id=US, release=release_5:
  • No significant bias detected (p = 0.181 )
  • Moderate revision volatility (Noise/Signal = 0.152 )

id=US, release=release_6:
  • No significant bias detected (p = 0.202 )
  • Moderate revision volatility (Noise/Signal = 0.13 )

This is where reviser moves beyond a reshape-and-plot package. The revision summary reports quantities that applied work often needs but usually rebuilds ad hoc: mean bias, quantiles, volatility, noise-to-signal ratios, and hypothesis tests for bias, serial correlation, and news-versus-noise interpretations.

In the bundled example, the early U.S. GDP releases over this sample show little evidence of systematic bias relative to the later benchmark. The package also supports efficient-release diagnostics, where the question is not only whether revisions exist, but when additional revisions stop adding meaningful information.

efficient_release <- get_first_efficient_release(early_releases, final_release)
summary(efficient_release)

Efficient release:  0 

Model summary: 

Call:
stats::lm(formula = formula, data = df_wide)

Residuals:
     Min       1Q   Median       3Q      Max 
-0.89186 -0.12669  0.02046  0.11475  0.97986 

Coefficients:
            Estimate Std. Error t value Pr(>|t|)    
(Intercept)  0.00299    0.02223   0.134    0.893    
release_0    0.97412    0.01692  57.567   <2e-16 ***
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

Residual standard error: 0.2518 on 166 degrees of freedom
  (10 observations deleted due to missingness)
Multiple R-squared:  0.9523,	Adjusted R-squared:  0.952 
F-statistic:  3314 on 1 and 166 DF,  p-value: < 2.2e-16


Test summary: 

Linear hypothesis test:
(Intercept) = 0
release_0 = 1

Model 1: restricted model
Model 2: final ~ release_0

Note: Coefficient covariance matrix supplied.

  Res.Df Df      F Pr(>F)
1    168                 
2    166  2 1.9283 0.1486

That is exactly the kind of result that is hard to see from a revision triangle alone but straightforward to formalize once the workflow is standardized. In this sample, the result points to the first release as already being statistically close to the later benchmark, which suggests subsequent revisions add relatively little systematic information.

From descriptive analysis to revision nowcasting

For many users, revision summaries will be the main use case. But reviser also includes model-based tools for users who want to treat revisions as an explicit latent-data problem. That matters if you need to make decisions on preliminary data but also want a structured way to estimate how those figures are likely to change later.

Two vignettes walk through nowcasting revisions with:

the generalized Kishor-Koenig family via kk_nowcast();
the Jacobs-Van Norden model via jvn_nowcast().

Both approaches cast the revision problem into state-space form, which makes it possible to estimate the dynamics of news and noise in successive data releases. For technical users, this is the part of the package that turns revision analysis from retrospective diagnosis into a forecasting problem.

Here is a compact kk_nowcast() example following the Kishor-Koenig workflow from the vignette for the Euro Area (EA).
The key idea is to first identify an efficient release e, then estimate the revision system on the corresponding panel of releases. In this euro area example, the efficient-release step selects e = 2, so the model treats the third published release as the earliest one that is already close to the later benchmark. That is a useful substantive result on its own: it suggests that most of the economically relevant signal arrives within the first few releases, while later revisions are smaller adjustments around that path.

gdp_ea <- reviser::gdp |>
  tsbox::ts_pc() |>
  dplyr::filter(
    id == "EA",
    time >= min(pub_date),
    time <= as.Date("2020-01-01")
  )

releases <- get_nth_release(gdp_ea, n = 0:14)
final_release <- get_nth_release(gdp_ea, n = 15)

efficient_release <- get_first_efficient_release(releases, final_release)

fit_kk <- kk_nowcast(
  df = efficient_release$data,
  e = efficient_release$e,
  model = "KK",
  method = "MLE"
)

summary(fit_kk)


=== Kishor-Koenig Model ===

Convergence: Success 
Log-likelihood: 125.7 
AIC: -231.41 
BIC: -198.23 

Parameter Estimates:
 Parameter Estimate Std.Error
        F0    0.633     0.131
      G0_0    0.950     0.031
      G0_1   -0.037     0.152
      G0_2   -0.181     0.220
      G1_0   -0.009     0.011
      G1_1    0.594     0.061
      G1_2    0.194     0.092
        v0    0.380     0.068
      eps0    0.008     0.001
      eps1    0.001     0.000

plot(fit_kk)

Diagnostic plot from the Kishor-Koenig nowcast example.

The fitted object contains estimated parameters, filtered and smoothed latent states, and plotting methods for the implied efficient-release path. That gives you a direct route from descriptive revision analysis to a state-space nowcast of future revisions. For a broader audience, the main takeaway is not the individual coefficients. It is that the model converges cleanly on this sample, summarizes the revision process in a compact latent-state form, and provides a practical way to judge whether a new release is likely to be revised materially later on. Substantively, the model separates persistent signal from transitory revision noise, so the output is useful when you want to judge whether new releases are likely to be revised materially.

What reviser adds

What stands out in reviser is not a single function, but the coherence of the workflow:

the package has explicit conventions for vintage data;
descriptive revision analysis and formal testing sit in the same API;
efficient-release analysis connects directly to applied questions about which release to trust;
nowcasting tools extend the same workflow rather than forcing a separate modeling stack.

If you work with real-time macroeconomic data, that combination is useful because revision analysis is usually fragmented across custom scripts, one-off spreadsheets, and package combinations that do not share a common data structure.

Try it and push it further

You can install the package from the rOpenSci R-universe:

install.packages(
  "reviser",
  repos = c("https://ropensci.r-universe.dev", "https://cloud.r-project.org")
)

Then start with the package site and vignettes:

docs: https://docs.ropensci.org/reviser
source: https://github.com/ropensci/reviser

We would be happy to hear feedback from those of you trying out the package with different datasets. If you have a real-time dataset with a different release structure, that would be a good stress test for the package. If you find gaps in the workflow or have a use case to share, open an issue or contribute an example. Revision analysis gets more useful as it becomes easier to compare workflows across datasets rather than rebuilding them from scratch each time.

rOpenSci News Digest, March 2026

rOpenSci — Mon, 30 Mar 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

rOpenSci Dev Guide 1.0.0: Trilingual and Improved

rOpenSci Software Peer Review’s guidance is gathered in an online book that keeps improving! It is now available in English, Spanish and Portuguese. Read more in the release announcement

Champions Program Update

We are still going through the Champions selection process, and we’re excited to share that the new group of mentors has already been selected and is now actively reviewing Champions applications.

This cohort brings together a wonderful mix of returning Champions stepping into mentorship roles, mentors continuing their contributions, and new members joining the program. The 2026 mentors are Andrea Gómez Vargas, Pablo Paccioretti, Alber Hamersson Sánchez Ipia, Erick Isaac Navarro Delgado, Francisco Cardozo, Luis Verde Arregoitia, Monika Ávila Márquez, Guadalupe Pascal, Pao Corrales, and Elio Campitelli. Together, they represent a diverse and vibrant community across Colombia, Mexico, Argentina, Brazil, and Bolivia, with some currently based in Switzerland, Canada, the United States, and Australia. We’re very happy to see this growing, interconnected network supporting the next cohort of Champions.

R-Universe update

You can now download artifacts and log files from R-Universe without being logged in with a GitHub account, for example https://ropensci.r-universe.dev/opencv#checktable.

Software review and usage of AI tools

Authors submitting new software for peer review are now required to explain potential usage of generative AI tools in their package development. All submission templates now include a mandatory check-box:

- [ ] Generative AI tools were used to produce some of the material in this submission.

If so, please describe usage, and include links to any relevant aspects of your repository.

This is the start of our updates to accommodate generative AI tools in package development, as described in our recent blog post. The next phase will involve updates to our Dev Guide, explaining requirements and recommendations for authors, reviewers, and editors. All updates are intended to permit generative AI tools to be used in any useful way, while minimising the burden on those who volunteer their own time to keep our software peer review service running.

Software review bot updates

The ropensci-review-bot now delivers an initial report to all new software pre-submissions and submissions, identifying the five most similar packages from both all rOpenSci packages, and all CRAN packages. The matches are generated by our ropensci-review-tools/pkgmatch package (itself reviewed in this review issue). Matching is based on an “term frequency-inverse document frequency” algorithm, using inverse document frequencies from all rOpenSci and CRAN packages. Similar package reports can also be manually triggered (by editors only) with @ropensci-review-bot similar packages, like in this example for the pkgmatch package itself.

Coworking

Read all about coworking!

Tuesday April 7th 2026, 9:00 Americas Pacific (16:00 UTC) “Getting to know the CSID Network” with Steffi LaZerte and cohosts Irene Ramos and Adamu Saleh Saidu.
- Learn more about the CSID Network
- Meet cohosts, Irene Ramos and Adamu Saleh Saidu, and learn more about the CSID Network and how you might get involved.
Tuesday May 5th 2026, 9:00 Australia Western (01:00 UTC) “Code Review with rOpenSci” with Steffi LaZerte and cohost Liz Hare.
- Explore resources for Code Review
- Sign up to volunteer to do software peer-review at rOpenSci
- Meet cohost, Liz Hare, and discuss resources for Code Review with rOpenSci.

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 📦

New packages

The following package recently became a part of our software suite:

suwo, developed by Marcelo Araya-Salas together with Jorge Elizondo-Calvo and Alejandro Rico-Guevara: Streamline searching/downloading of nature media files (e.g. audios, photos) from online repositories. The package offers functions for obtaining media metadata from online repositories, downloading associated media files and updating data sets with new records. It has been reviewed by Eric R. Scott and Hugo Gruson.

Discover more packages, read more about Software Peer Review.

New versions

The following eleven packages have had an update since the last newsletter: cffr (v1.3.0), pkgmatch (v0.5.2), tarchetypes (0.14.1), rgbif (v3.8.5), saperlipopette (v0.1.1), gutenbergr (v0.5.0), trud (v0.2.1), naijR (v0.7.0), sasquatch (v0.1.3), lingtypology (v1.1.25), and rerddap (v1.2.3).

Post on dfms release: Releasing dfms 1.0: Fast and Feature-Rich Estimation of Dynamic Factor Models in R.

Software Peer Review

There are fifteen recently closed and active submissions and 5 submissions on hold. Issues are at different stages:

One at ‘6/approved’:
- suwo, Access Nature Media Repositories Through R. Submitted by Marcelo Araya-Salas.
One at ‘5/awaiting-reviewer(s)-response’:
- pkgmatch, Find R Packages Matching Either Descriptions or Other R Packages. Submitted by mark padgham.
Two at ‘4/review(s)-in-awaiting-changes’:
- logolink, An Interface for Running NetLogo Simulations. Submitted by Daniel Vartanian.
- galamm, Generalized Additive Latent and Mixed Models. Submitted by Øystein Sørensen. (Stats).
Six at ‘3/reviewer(s)-assigned’:
- pvEBayes, Empirical Bayes Methods for Pharmacovigilance. Submitted by Yihao Tan. (Stats).
- saperlipopette, Create Example Git Messes. Submitted by Maëlle Salmon.
- ernest, A Toolkit for Nested Sampling. Submitted by Kyle Dewsnap. (Stats).
- rcrisp, Automate the Delineation of Urban River Spaces. Submitted by Claudiu Forgaci. (Stats).
- reviser, Tools for Studying Revision Properties in Real-Time Time Series Vintages. Submitted by Marc Burri.
- priorsense, Prior Diagnostics and Sensitivity Analysis. Submitted by Noa Kallioinen. (Stats).
Two at ‘2/seeking-reviewer(s)’:
- nycOpenData, Convenient Access to NYC Open Data API Endpoints. Submitted by Christian Martinez.
- RAMEN, RAMEN: Regional Association of Methylome variability with the Exposome and geNome. Submitted by Erick Navarro-Delgado.
Three at ‘1/editor-checks’:
- RAQSAPI, A Simple Interface to the US EPA Air Quality System Data Mart API. Submitted by mccroweyclinton-EPA.
- 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).

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

On the blog

Software Review

Software Review in the Era of AI: What We Are Testing at rOpenSci by Mark Padgham, Noam Ross, Maëlle Salmon, Yanina Bellini Saibene, Mauro Lepore, Emily Riederer, Jouni Helske, and Francisco Rodriguez-Sanchez. rOpenSci is testing preliminary policies on the use of generative AI tools, with proposed updates to documentation and procedures for authors submitting software for review, for editors, and for reviewers.
rOpenSci Dev Guide 1.0.0: Trilingual and Improved by Maëlle Salmon, Mark Padgham, and Noam Ross. Updates in version 1.0.0 of the online book ‘rOpenSci Packages: Development, Maintenance, and Peer Review’. Other languages: rOpenSci Dev Guide 1.0.0: Trilingüe y mejorada (es), Guia de desenvolvimento da rOpenSci 1.0.0: trilíngue e aprimorado (pt).

Breaking Release of the patentsview R Package by Russ Allen and Chris Baker. Breaking Release of the patentsview R Package.

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?.

NLMR, R package to simulate neutral landscape models. Issue for volunteering.
landscapetools, R package for some of the less-glamorous tasks involved in landscape analysis. Issue for volunteering.
hddtools, Tools to discover hydrological data, accessing catalogues and databases from various data providers. Issue for volunteering.
qualtRics, download Qualtrics survey data. 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 tips for R package developers. 👀

A new R core member!

The R Foundation announced that Heather Turner has joined the R Core Team! 🎉

How to browse the R mailing lists

The official mailing lists of the R project like R-package-devel are full of important and useful information. How to browse them, given that the default website is not easy to search? You can use the mail-archive website (thanks to Hugo Gruson for the reminder!) or a new project by James Balamuta: the R Mailing Lists Archive!

“Claude Code: Setting up ast-grep with R support”

Thanks to Mauro Lepore for sharing this blog post by Emil Hvitfeldt: “Claude Code: Setting up ast-grep with R support”. ast-grep is a tool for querying code by syntax rather than brittle regular expressions. The blog post describes how to add R support to this tool, and how to take advantage of it when using Claude.

On muffling messages from packages

A follow-up on our post “Please Shut Up! Verbosity Control in Packages”.

With the {cli} R package you can change the default handler for messages. See the docs. It seems mostly used to muffle messages, e.g. in flir.
Here’s how the usethis R package muffles gert message selectively.

Last words

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

If you haven’t subscribed to our newsletter yet, you can do so via a form. Until it’s time for our next newsletter, you can keep in touch with us via our website and Mastodon account.

Breaking Release of the patentsview R Package

rOpenSci — Tue, 10 Mar 2026 00:00:00 +0000

The patentsview R package was created by Chris Baker to simplify interactions with the PatentsView API as announced in Chris’ blog post in 2017. The API can be queried for data from US patents granted since 1976 as well as patent applications since 2001 (not all going on to become granted patents).
As shown in the package’s vignettes, location data can be mapped, charts of assignees can be created etc. using other R packages, only limited by the developer’s imagination.

Fast-forwarding to today finds us in a precarious position as the PatentsView API team had made breaking changes and obsoleted the original API (all calls to the original endpoints return 410 Gone). As such we have spent some time now updating patentsview to work with these API changes. The updated patentsview package is now on CRAN but, unfortunately, as this Tech Note was being prepared the PatentsView API team made troubling changes.

In late February they replaced their forum with a message saying the page was temporarily unavailable. Further, they have also removed the link to request an API key, so it’s unclear whether they’d honor requests for API keys using the link below. Nothing has been officially announced but the long term viability of the API seems uncertain.

🍴 Here you’ve come to a fork (and knife) in the road, continue reading if you are/were using the original version of the patentsview package, and we’ll guide you through the necessary changes. If you have an interest in US patent data but haven’t used the patentsview package yet (and are willing to take the risk!), check out the vignette reworked from Chris’ original blog post to use the new version of the R package and API.

New changes to the API:

Users will need to request an API key and set an environmental variable PATENTSVIEW_API_KEY to this value.
Endpoint changes:
- The nber_subcategories, one of the original seven endpoints, was removed
- cpc_subsections is now cpc_group
- The remaining five original endpoints went from plural to singular, patents is now patent, for example. Interestingly, the returned data structures are still plural for the most part.
- There are now 27 endpoints, and more than one may need to be called to retrieve fields that were available from a single call to one of the original endpoints
- Some of the endpoints now return HATEOAS (Hypermedia as the Engine of Application State) links that can be called to retrieve additional data
Some fields are now nested and need to be fully qualified when used in a query, for instance, search_pv('{"cpc_current.cpc_group_id":"A01B1/00"}') when using the patent endpoint. In the fields parameter, nested fields can be fully qualified or a new API shorthand can be used, which allows you to specify group names. When group names are used, all of the group’s nested fields will be returned. For example, defining fields = c("assignees") when using the patent endpoint means that all nested assignees’ fields will be returned by the API.
Some field names have changed, most significantly, patent_number is now patent_id, and some fields were removed entirely, for instance, rawinventor_first_name and rawinventor_last_name.
The original version of the API had queryable fields and additional fields which could be retrieved but couldn’t be part of a conditional query. That notion does not apply to the new version of the API as all fields are now queryable. You may be able to simplify your code if you found yourself doing post processing on returned data because a field you were interested in was not queryable.
Now there isn’t supposed to be a difference between operators used on strings vs full text fields, as there was in the original version of the API. See the tip below the Syntax section.
Result set paging has changed significantly. This only matter to users implementing their own paging, as the package continues to handle result set paging with search_pv()’s all_pages = TRUE. There is a new Result set paging vignette to explain the API’s paging, using the size and after parameters rather than page and per_page.
Result set sizes are seemingly unbounded now. The original version of the API capped result sets at 100,000 rows.

The API team also renamed the API, PatentsView’s Search API is now the PatentSearch API. Note that the R package will retain its name, continue to use library(patentsview) to load the package.

New changes to the R package:

Throttling is now enforced by the API and handled by the R package (sleep as specified by the throttle response before a retry)
There are five new vignettes
- API Changes
- Converting an existing script
- Result set paging, should custom paging be needed
- Understanding the API, the API team’s jupyter notebook converted to R and enhanced
- Accessing patent data with the patentsview package, the blog post that announced the original version of the R package has been updated to work with the new version of the API
The R package changed internally from using httr to httr2. This only affects users if they passed additional arguments (...) to search_pv(). Previously if they passed config = httr::timeout(40) they’d now pass timeout = 40 (name-value pairs of valid curl options, as found in curl::curl_options() see req_options)
Now that the R package is using httr2, users can make use of its last_request() method to see what was sent to the API. This could be useful when trying to fix an invalid request. Also fun would be seeing the raw API response.

httr2::last_request()
httr2::last_response()
httr2::last_response() |> httr2::resp_body_json()

A new function was added retrieve_linked_data() to retrieve data from a HATEOAS link the API sent back, retrying if throttled
An existing function was removed. With the API changes, there is less of a need for cast_pv_data() which was previously part of the R package. The API now returns most fields as appropriate types, boolean, numeric etc., instead of always returning strings.

Online API documentation

The PatentsView API team has thoughtfully provided a Swagger UI page for the new version of the API at https://search.patentsview.org/swagger-ui/. Think of it as an online version of Postman already loaded with the API’s new endpoints and returns. The Swagger UI page documents what fields are returned by each endpoint on a successful call (http response code 200). You can even send in requests and see actual API responses if you enter your API key and press an endpoint’s “Try it out” and “Execute” buttons. Even error responses can be informative, the API’s X-Status-Reason response header usually points out what went wrong.

In a similar format, the updated API documentation lists what each endpoint does. Additionally, the R package’s fieldsdf data frame has been updated, now listing the new set of endpoints and fields that can be queried and/or returned. The R package’s reference pages have also been updated.

Final thoughts

As shown in the updated Top Assignees vignette, there will be occasions now where multiple API calls are needed to retrieve the same data as in a single API call in the original version of the API and R package. Additionally, the reworked rOpenSci post explains what changes had to be made since assignee latitude and longitude are no longer available from the patent endpoint.

Issues for the R package can be raised in the patentsview repo.

As we mentioned at the start, the future of the PatentsView API is a bit uncertain. PatentsView is funded by the USPTO, who may be looking to cut costs. However, until we know for certain, we hope patentsview serves you well. If nothing else, it’s been a great run, starting in 2015 for the API and 2017 for the R package!

rOpenSci Dev Guide 1.0.0: Trilingual and Improved

rOpenSci — Mon, 02 Mar 2026 00:00:00 +0000

Read it in: Español.

Read it in: Português.

rOpenSci Software Peer Review’s guidance is gathered in an online book that keeps improving! This blog post summarises what’s new in our Dev Guide 1.0.0, with all changes listed in the changelog.

Now available in Portuguese!

Our guide is now trilingual (English, Spanish, Portuguese)!

Find more about the awesome Portuguese translation project, initiated and powered by our Lusophone members in our blog post.

The translation project and ongoing multilingual maintenance uses our babelquarto package to render multilingual Quarto books and websites. It was recently peer-reviewed by Ella Kaye and João Granja-Correia.

We’re actively working on our babeldown package to create and update translations using the DeepL API.

In the dev guide itself, tools useful for internationalizing packages are mentioned: potools, the experimental rhelpi18n package, selecting a language for a pkgdown website.

Policy Updates

We made some changes to rOpenSci policies and scope:

New category for rOpenSci internal and peer-review tools.
Updates to the data retrieval category.
New explicit rule to only submit one package at a time.
New requirement to not call the default branch “master”.
Removed requirement to use a codemeta.json file, now deprecated. Codemeta continues to be actively used and developed, but we have found it redundant with other metadata and Codemeta can generate these data as-needed from DESCRIPTION files.

Editor Guide, Author Guide & Reviewer Guide

The guides that live in our guide. 😸

The whole editor guide was has been restructured to follow the typical flow of submissions, and to better explain how to use the software-review dashboard. We added a section on challenges, and documented how to put the system on vacation (which we generally do over the new year period).

Likewise, we improved the organization and content of the author guide (thanks to Alec Robitaille and Joan Maspons).

In the reviewer guide, we removed the external link to the no-longer maintained Mozilla Review guide (one of our early design sources for peer-review) in favor of explicit enumerated items.

Packaging Best Practices

In the packaging guide (another guide within the guide!), we added guidance for choosing example datasets. Furthermore, we created a section for Packages wrapping external software. The licencing section now explicitly requires acknowledging authors of bundled code. Last but not least, the section about dependencies recommends checking the development status of dependencies.

The whole book now mentions the Air CLI every time it mentions the styler package, as Air can be viewed as styler’s successor.

In the chapter about Package evolution, we added guidance on deprecating data, and explained the drawbacks of renaming a widely-used package.

Testing guidance

We updated our testing guidance with

a mention of tinytest as an alternative to testthat;
a note on keeping tests written with testthat self-contained.

Package Documentation

With particular thanks to Alasdair Warwick , we improved the documentation 😉 of our documentation building system, including:

More details on the technical aspects of docs building for rOpenSci packages;
Updated math guidance following pkgdown’s update.

We also clarified different strategies to document internal functions, thanks to Claudiu Forgaci.

Metadata & Package Information

We documented more ways to acknowledge contributors:

in the authorship section of the packaging guide, with Research Organization Registry (ROR) IDs;
in the chapter about collaboration, the allcontributors R package.

Conclusion

In this post we summarized the changes in the latest version of our book “rOpenSci Packages: Development, Maintenance, and Peer Review”. We are thankful for all contributions that created this release. We are already working on the next version. Don’t hesitate to help us shape it by opening an issue!

Software Review in the Era of AI: What We Are Testing at rOpenSci

rOpenSci — Thu, 26 Feb 2026 00:00:00 +0000

The advent of large language models (LLMs) and generative AI tools has changed the nature of software development and of software review. These developments are complex, challenging, and controversial, but require action to maintain and grow rOpenSci’s programs and community. In response, we are starting with a preliminary set of policies to clarify our expectations for use of generative AI tools by authors, reviewers, and editors in software peer-review. This blog post describes the challenges ahead and initial changes we are making.

Challenge: Maintaining our core values

Our top challenge is maintaining our core values.

A central value for rOpenSci is fostering a welcoming community, in particular through supporting and encouraging people who might otherwise feel excluded. Generative AI tools can help with that. Large language models and generative AI tools may make many coding tasks easier and quicker, and can expand the community of people able to contribute to open source software and the OSS community.

Yet there are many downsides to generative AI tools which challenge our core values. pyOpenSci has done an excellent job exploring these in this blog post. They fall into two broad areas.

First, use of AI can in many cases degrade the quality of both open-source scientific code and the process by which we create it. LLMs can in many cases produce incorrect outputs, fail to generate time or efficiency benefits, or degrade the process of learning to code or the social cohesion of the community. A core design of our software peer-review is to drive community building through healthy interactions between authors, reviewers, and contributors. We aim to improve and promote the quality of research software, to facilitate good development practices among researchers, to foster collaboration, and to curate a community of practice. Any use of AI must be compatible with that goal.

Second, AI has the potential for tremendous broader impacts or externalities: environmental impacts, amplification of bias, infringement of creative and intellectual rights, or even driving increases in social and economic inequality. We have both collective and individual responsibilities to address these impacts, which include the right to opt out of uses of AI.

Challenge: Changing the focus of software reviews

Editors and reviewers at rOpenSci are volunteers who devote their own time to help others improve the quality of their software. Our review system works because they have always been able to assume that all aspects of code submitted for review have reflected decisions made by the human authors of software. That, in turn, has ensured that the efforts of editors and reviewers are proportional to the primary efforts of software authors.

Generative AI tools potentially change both of these situations. They enable software to be produced with relatively little human input or oversight, which means editors and reviewers may put more consideration into software design, structure, and function than submitting authors. We do not want software review to become a service in which our human volunteers validate largely AI-generated software. That would put at risk the equal and constructive interaction of review, and likely reduce the motivation of editors and reviewers. We need to ensure that our software review process remains focused on the decisions, designs, and implementations of the submitting authors.

One option is requesting authors to outline the areas that have been AI generated, and specifying the scope of their own work. However, this could result in our previously holistic process becoming one where only defined aspects or sections of software end up being reviewed. Authors declaring that a certain tool was used to generate all tests may lead one reviewer to completely ignore those tests, while another reviewer may be passionately engaged in the ways by which exactly that tool writes tests.

In any case, this will require everybody to be as open as possible about what, where, and how generative AI tools may have been used.

Response: Preliminary policies

Our initial policy updates are not intended to restrict use of generative AI tools, but to encourage the rOpenSci community to approach these tools in ways that encourage, rather than diminish, healthy community interactions.

Similar updates have already been implemented by both the Journal of Open Source Software and pyOpenSci, and we are indebted to the work of all those who contributed to these policy statements.

Importantly, our software review policies and practices have evolved over many years in response to community engagement and feedback. The introduction of policies addressing generative AI tools is a part of that evolution, and these policies will also evolve further in responses to community engagement, and changing community practices.

No change in scope

One potential response would be a change in the scope of packages we review. JOSS has updated their scope definition to, among other things, require a longer record of continuous development, along with other criteria, such as evidence of impact and design. At rOpenSci, authors often seek feedback on early-stage software. Our review process commonly involves deep and broad consideration through extensive exchanges between authors, reviewers, and editors. We are confident that this extends to many of the areas emphasized by JOSS’s updated criteria, and we therefore see no need to explicitly change either the scope or focus of review.

Requiring openness of AI usage

Our policy updates aim to retain the same degree of openness and transparency we have always practiced, while extending to the new area of generative AI tools and practices. We cannot know the eventual impact that generative AI tools may have on software review processes and practices at rOpenSci, and can ask only for an utmost degree of transparency from all involved.

We now describe specific updates to both our practices and policies for authors, for editors, and for reviewers. Software review aims to provide authors with feedback on their practices and choices, and not just on the lines of code they or an AI generated. We also value the time and effort of editors and reviewers, and want them to be able to focus on the practices and choices of authors.

Practical application: for authors

Authors who do not use generative AI tools will submit as always, with no extra requirements. Those who do use such tools will be asked to describe their use, and to affirm that all generated material has been carefully reviewed by the authors. We want these descriptions to help reviewers and editors to understand how they can best review code and provide useful feedback.

We will be modifying our submission template to include this required section, and will be updating the Guide for Authors with additional guidance.

A minimal example might be a statement that “we’re not very proficient in C, so we used an LLM to generate most of the code for the C algorithm.” This might guide reviewers to pay particular attention to the tests for that part of the package. A more extensive description might be that, “We used <tool-of-choice> to generate all tests, but have read, edited, and manually stepped through each test ourselves.” This can help reviewers decide whether to pay more or less attention to the tests depending on their interests. Either way, knowing that tests were generated by AI tools is useful and important to the review process.

Descriptions may refer to relevant documentation in the repository, such as:

Design documents which highlight key components and explain their design;
“agents.md” or equivalent files, along with explanations of how these have been used, along with clear description of the roles of the submitting authors;
Overviews of developmental histories, for example in “NEWS.md” or equivalent files.

We intend to maintain our requirement for “CONTRIBUTING.md” files, as any generative AI tools can also be directed to treat that as an “agents.md” file.

This is our intended addition to the templates for authors submitting software for review:

## Use of Generative AI

- [ ] Generative AI tools were used to produce some of the material in this submission.

If so, please describe: <!-- refer to our AI policies at http:// ... -->
If your repository includes an "agents.md" file or equivalent, please provide a link, and describe how this has been used in the development of your package.

An example of such a description can be found in this recent software review submission.

Practical application: for editors

Editors are the first to view software submitted to rOpenSci, and generally complete an initial Editors checklist indicating whether they think a package may proceed to review. This checklist will also include an additional item:

- [ ] **Use of generative AI tools**: If the authors have used generative AI tools, have they sufficiently described their usage?

This item will also require no additional action by editors unless authors have used generative AI tools.

Initial editorial considerations have until now been largely technical, including many of the aspects now automated by our pkgcheck system. In response to this new checklist item, editors may broaden their consideration to whether a package has had sufficient human contribution to be worth reviewing, alongside considerations of additional factors such as:

Clear statements of package motivation and importance.
Package development history.
Evidence of design decisions motivating the software.

When recruiting reviewers for a package, editors may describe authors’ AI usage where relevant to help them understand the nature of the package and demands of review.

Practical application: for reviewers

Review processes at rOpenSci frequently involve reviewers recommending potential improvements, and authors then implementing those. In adapting to use of generative AI tools, we will strive to maintain the same culture of constructive feedback. We hope that authors will provide sufficient information on any use of generative AI tools to guide reviewers towards aspects of their software requiring particular attention.

Reviewers are permitted to use generative AI tools in preparing reviews for rOpenSci, but their use must meet the same criteria of supporting the goals of review. Our Guide for Reviewers will be updated to note the following points:

Generative AI tools may be used to aid the review process, but all review text must reflect the judgement of the reviewer.
Typical and acceptable use of generative AI tools in software review includes getting an overview of software design, structure, and function.

Updates to the Guide for Reviewers will also include examples of productive use of generative AI tools in the review process. We aim to run pilots over the course of this year to test where in the review process AI can best be used to improve everyone’s experience, and to provide more robust guidelines and custom tools.

Reviewers may also consider AI use in choosing whether to volunteer as a reviewer of a package, and authors should be aware that extensive AI use could increase the time to find reviewers.

Moving forward

This is our first pass at providing guidelines governing the use of generative AI to ensure rOpenSci software review continues to improve while retaining its essential values.

With more package submissions having some component of AI contribution, the editorial board thought it essential to provide these updates to manage the process as we learn more about what works and what does not.

We invite you to further discuss the evolving role of AI in software review in this issue, and more importantly to join us as an author or reviewer in peer review, so we can learn together!