Mark Padgham’s Tools Strengthened rOpenSci’s Software Peer Review
Software peer review depends on careful human judgment, but the right tools can make that work more consistent and manageable. At rOpenSci, Mark Padgham helped build both: he shaped the review of statistical software and developed much of the infrastructure that supports package submissions, editorial work and community contributions. He leaves the organization at the end of October, closing a period of work that connected editorial standards with the practical tools needed to apply them.
Padgham joined rOpenSci in December 2019 to help expand peer review into statistical software. Since then, his work has reached authors, reviewers and editors across the organization. Anyone who has submitted or reviewed an rOpenSci package has likely encountered tools he built or maintained, even if the underlying work happened out of sight. That connection between visible editorial decisions and less visible software infrastructure is central to his contribution.
Setting standards for statistical packages
Statistical software calls for a different review lens from a package that connects to an API. Reviewers need ways to assess how a package implements statistical methods, and authors need clear expectations for documenting their work. A package can be tidy and easy to install while still leaving important questions about its methods unanswered. Review standards help make those questions part of the submission process instead of relying on each reviewer to invent an approach from scratch.
Padgham helped define those expectations, brought in editors with statistical expertise and turned the group’s thinking into standards and a supporting guide. The work was discussed in an rOpenSci community call on statistical software testing and peer review. That kind of shared guidance matters because statistical packages can serve very different purposes, and reviewers need a common basis for asking about implementation, testing and documentation without treating every project as identical.
He also developed tools to make the process practical. pkgstats summarizes a package’s structure, helping authors and editors understand what a submission contains and how it is organized. srr gives authors a way to document how their package meets the statistical software standards. One tool helps make a package easier to inspect; the other gives authors a way to explain how they approached the standards. Together, they turn broad expectations into work that can be discussed during review.
rOpenSci published its first peer-reviewed statistical packages in November 2022. Since then, more than 26 packages have gone through the process. That record shows the review model has moved beyond a set of proposed principles and into repeated use. This is more significant than it looks: a standard earns its place when authors and editors can apply it to real submissions, including projects with different methods and structures.
Automation behind the review process
Review remains a human activity, but automation handles repeatable checks and helps keep submissions moving. Padgham built and maintained pkgcheck, which checks submitted packages, as well as a GitHub Action that lets developers run those checks in their own repositories. These tools can surface routine issues earlier, giving authors a chance to address them and reviewers a more useful starting point. They don't settle questions of quality or scientific judgment. They make the mechanical parts of review easier to see and handle.
pkgcheck draws on goodpractice, another package Padgham maintained and that received a set of updates and extensions. He also maintained Buffy, the bot that powers rOpenSci’s GitHub chat review system. Editors use it to assign reviewers, track deadlines and advance submissions through simple comments. That may sound like administrative detail, but a review process depends on such coordination: without a clear way to see who is doing what, editorial effort can get swallowed by status tracking.
And this is the part most people overlook: automation only helps if it fits the way people actually work. A check that authors can run in their own repositories can make feedback more actionable, while a bot that works inside editors’ existing process can reduce friction. Neither removes the need for careful review. They help keep that human attention focused where it matters.
Guiding the people and process
In early 2025, Padgham became rOpenSci’s Software Review Lead, taking responsibility for editorial management, the editorial board and plans for its future. The role also brought new questions about how the process should adapt. His work helped guide rOpenSci’s response to AI-assisted submissions, including its first AI policy, and to large submissions, which led to the organization’s first group peer review.
Those changes put pressure on the review process to be clear about authorship, responsibilities and how editorial work gets organized. The source material doesn't specify the policy’s rules or the group review’s format, but both developments show the organization addressing cases that can challenge a process built around individual submissions. Here’s the thing: a review system is defined partly by its standards and partly by how it responds when a submission doesn’t fit the usual pattern.
His contributions extended beyond review operations. In Beyond GitHub, Padgham examined alternatives to the platform and what relying less on a single service could mean for a community like rOpenSci. That question reaches beyond software preference. Communities that organize work on a platform can become dependent on its tools and conventions, so considering alternatives is a way to think through how community work might continue under different conditions. He also served on the organization’s Code of Conduct committee, a reminder that sustaining a technical community involves its norms and relationships as well as its code.
Tools beyond rOpenSci
Several of Padgham’s projects serve the wider R community. The allcontributors package helps projects recognize contributors whose work may not involve writing code. repometrics explores ways to understand repository activity and health, while deposits focuses on placing research data and software in trusted repositories. These projects address different needs, but each concerns the work around producing and maintaining research software: recognizing contributions, understanding activity and preserving outputs.
If you're working in this space, the range of those projects offers a useful reminder that software infrastructure isn't limited to code that runs a method. Credit, maintenance signals and access to research outputs also shape whether a project can be understood and reused. The numbers here are underwhelming as a measure of impact: a count of reviewed packages can't capture the people who used the tools, the habits they helped establish or the work made easier along the way.
What the work leaves behind
Padgham’s legacy at rOpenSci is visible in the standards reviewers use, the automation behind submissions and the packages that help researchers build and share software. These systems give the community a practical foundation to keep improving as its projects and review challenges change. That said, tools and guidance need ongoing care; their value depends on whether the community continues to maintain and use them as its needs shift.
His departure marks a transition for work that spans editorial practice and technical infrastructure. Those pieces are connected: standards need tools that help people apply them, and tools need a process that makes clear what they’re for. Readers who have benefited from his work can contact Mark and follow his work through his website and social media.
