Our onboarding process, thatensures that packages contributed by the community undergo atransparent, constructive, non adversarial and open review process,involves a lot of work from many actors: authors, reviewers and editors;but how much work ? Managing the effort involved in the peer-reviewprocess is a major part of ensuring its sustainability and quality.

rOpenSci’s package review system (akaonboarding) is one of our keyactivities to improve quality and sustainability of scientific Rpackages. Theeditorial team are constantly working towards improving the experiencefor both authors and reviewers. After our first year, we surveyedauthors andreviewers whoparticipated in our onboarding process to help us better understandwhat’s working well and where there is room for improvement.

If you read my reflection #1 on rOpenSci Onboarding, then you know I see value in the Onboarding process. A LOT of value even. This post is about where that value lies.

To give you an idea of where I am in my R developer germination, I’d just started reading about testing when I received an email from @rOpenSci inviting me to review the weathercan package. Many of us in the R community feel like imposters when it comes to software development. In fact, as a statistician, it was a surprise to me when I was recently called a developer.

It all started January 26 ^th this year when I signed up to volunteer asa reviewer for R packages submitted to rOpenSci. My main motivation forwanting to volunteer was to learn something new and tocontribute to the R open source community. If you are wondering why thepeople behind rOpenSci are doing this, you can read How rOpenSci uses Code Review to Promote Reproducible Science.

Contributing to an open-source community without contributing code is an oft-vaunted idea that can seem nebulous. Luckily, putting vague ideas into action is one of the strengths of the rOpenSci Community, and their package onboarding system offers a chance to do just that.