<p><div><div><div><div data-show-faces="false" data-height="21" data-width="100" data-layout="button_count" data-send="true" data-href="https://www.r-bloggers.com/experiences-as-a-first-time-ropensci-package-reviewer/"></div></div><div></div></div><div></div></div>
<div>
(This article was first published on <strong><a href="http://ropensci.org/blog/blog/2017/09/08/first-review-experiences"> rOpenSci Blog</a></strong>, and kindly contributed to <a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers)</a> </div>
<p>It all started January 26<sup>th</sup> this year when I signed up to volunteer as<br>
a reviewer for R packages submitted to rOpenSci. My main motivation for<br>
wanting to volunteer was to learn something new and to<br>
contribute to the R open source community. If you are wondering why the<br>
people behind rOpenSci are doing this, you can read <a rel="nofollow" href="https://www.numfocus.org/blog/how-ropensci-uses-code-review-to-promote-reproducible-science/" target="_blank">How rOpenSci uses Code Review to Promote Reproducible Science</a>.</p>
<p>Three months later I was contacted by <a rel="nofollow" href="https://twitter.com/masalmon" target="_blank">Maelle Salmon</a> asking whether I was interested in<br>
reviewing the R package <a rel="nofollow" href="https://github.com/ropensci/patentsview" target="_blank"><code>patentsview</code></a> for rOpenSci. And yes, I<br>
was! To be honest I was a little bit thrilled.</p>
<p>The packages are submitted for review to rOpenSci via an issue to their<br>
GitHub repository and also the reviews happen there. So you can check out<br>
<a rel="nofollow" href="https://github.com/ropensci/onboarding/issues" target="_blank">all previous package submissions and reviews</a>.<br>
With all the information you<br>
get from rOpenSci and also the help from the editor it is straightforward<br>
to do the package review. Before I started I read the<br>
reviewer guides (links below) and checked out a few of the existing<br>
reviews. I installed the package <code>patentsview</code> from GitHub and also<br>
downloaded the source code so I could check out how it was implemented.</p>
<p>I started by testing core functionality of the package by<br>
running the examples that were mentioned in the README of the<br>
package. I think this is a good<br>
starting point because you get a feeling of what the author wants to<br>
achieve with the package. Later on I came up with my<br>
own queries (side note: this R package interacts with an API from which<br>
you can query patents). During the process I used to switch between<br>
writing queries like a normal user of the package<br>
would do and checking the code. When I saw something in the code that<br>
wasn't quite clear to me or looked wrong I went back to writing new<br>
queries to check whether the behavior of the methods was as expected.</p>
<p>With this approach I was able to give feedback to the package author<br>
which led to the inclusion of an additional unit test, a helper function<br>
that makes the package easier to use, clarification of an error message<br>
and an improved documentation. You can find the review I did <a rel="nofollow" href="https://github.com/ropensci/onboarding/issues/112" target="_blank">here</a>.</p>
<p>There are several R packages that helped me get started with my review,<br>
e.g. <a rel="nofollow" href="https://github.com/hadley/devtools" target="_blank"><code>devtools</code></a> and<br>
<a rel="nofollow" href="https://github.com/MangoTheCat/goodpractice" target="_blank"><code>goodpractice</code></a>. These<br>
packages can also help you when you start writing your own packages. An<br>
example for a very useful method is <code>devtools::spell_check()</code>, which<br>
performs a spell check on the package description and on manual pages.<br>
At the beginning I had an issue with <code>goodpractice::gp()</code> but Maelle Salmon<br>
(the editor) helped me resolve it.</p>
<p>In the rest of this article you can read what I gained personally from doing a<br>
review.</p>
<h2>Contributing to the open source community</h2>
<p>When people think about contributing to the open source community, the<br>
first thought is about creating a new R package or contributing to one<br>
of the major packages out there. But not everyone has the resources<br>
(e.g. time) to do so. You also don't have awesome ideas every other day<br>
which can immediately be implemented into new R packages to be used by<br>
the community. Besides contributing with code there are also lots of<br>
other things than can be useful for other R users, for example writing<br>
blog posts about problems you solved, speaking at meetups or reviewing<br>
code to help improve it. What I like much about reviewing code is that<br>
people see things differently and have other experiences. As a reviewer,<br>
you see a new package from the user's perspective which can be hard for<br>
the programmer themselves. Having someone else<br>
review your code helps finding things that are missing because they seem<br>
obvious to the package author or detect code pieces that require more<br>
testing. I had a great feeling when I finished the review, since I had<br>
helped improve an already amazing R package a little bit more.</p>
<h2>Reviewing helps improve your own coding style</h2>
<p>When I write R code I usually try to do it in the best way possible.<br>
<a rel="nofollow" href="https://google.github.io/styleguide/Rguide.xml" target="_blank">Google's R Style Guide</a><br>
is a good start to get used to coding best practice in R and I also<br>
enjoyed reading <a rel="nofollow" href="https://github.com/timoxley/best-practices" target="_blank">Programming Best Practices<br>
Tidbits</a>. So normally<br>
when I think some piece of code can be improved (with respect to speed,<br>
readability or memory usage) I check online whether I can find a<br>
better solution. Often you just don't think something can be<br>
improved because you always did it in a certain way or the last time you<br>
checked there was no better solution. This is when it helps to follow<br>
other people's code. I do this by reading their blogs, following many R<br>
users on Twitter and checking their GitHub account. Reviewing an R<br>
package also helped me a great deal with getting new ideas because I<br>
checked each function a lot more carefully than when I read blog posts.<br>
In my opinion, good code does not only use the best package for each<br>
problem but also the small details are well implemented. One thing I<br>
used to do wrong for a long time was filling of data.frames until I<br>
found a better (much faster)<br>
<a rel="nofollow" href="https://stackoverflow.com/a/29419402" target="_blank">solution on stackoverflow</a>.<br>
And with respect to this you<br>
can learn a lot from someone else's code. What I found really cool in<br>
the package I reviewed was the usage of small helper functions (see<br>
<a rel="nofollow" href="https://github.com/ropensci/patentsview/blob/c03e1ab2537873d7a9b76025b0072953efb475c1/R/utils.R" target="_blank">utils.R</a>).<br>
Functions like <code>paste0_stop</code> and <code>paste0_message</code> make the rest of the<br>
code a lot easier to read.</p>
<h2>Good start for writing your own packages</h2>
<p>When reviewing an R package, you check the code like a really observant<br>
user. I noticed many things that you usually don't care about when using<br>
an R package, like comments, how helpful the documentation and the<br>
examples are, and also how well unit tests cover the code. I think that<br>
reviewing a few good packages can prepare you very well for writing your<br>
own packages.</p>
<h2>Do you want to contribute to rOpenSci yourself?</h2>
<p>If I motivated you to become an rOpenSci reviewer, please sign up! Here<br>
is a list of useful things if you want to become an rOpenSci reviewer<br>
like me.</p>
<ul>
<li>
<p><a rel="nofollow" href="https://ropensci.org/onboarding/" target="_blank">Form to sign up (just takes a minute)</a></p>
</li>
<li>
<p><a rel="nofollow" href="http://onboarding.ropensci.org/" target="_blank">Information for reviewers</a></p>
</li>
<li>
<p><a rel="nofollow" href="https://mozillascience.github.io/codeReview/review.html" target="_blank">Mozilla reviewing guide</a></p>
</li>
<li>
<p>While writing this blog post I found a nice article about <a rel="nofollow" href="http://www.tidyverse.org/articles/2017/08/contributing/" target="_blank">contributing<br>
to the tidyverse</a> which is<br>
mostly also applicable to other R packages in my opinion.</p>
</li>
</ul>
<p>If you are generally interested in either submitting or reviewing an R package, I would like to invite you to the <a rel="nofollow" href="https://ropensci.org/blog/blog/2017/08/31/comm-call-v14" target="_blank"> Community Call on rOpenSci software review and onboarding</a>.</p>
	<p>
<div>
<div>To <strong>leave a comment</strong> for the author, please follow the link and comment on their blog: <strong><a href="http://ropensci.org/blog/blog/2017/09/08/first-review-experiences"> rOpenSci Blog</a></strong>.</div>
<hr>
<a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers.com</a> offers <strong><a rel="nofollow" href="https://feedburner.google.com/fb/a/mailverify?uri=RBloggers">daily e-mail updates</a></strong> about <a rel="nofollow" href="https://www.r-project.org/" title="The R Project for Statistical Computing">R</a> news and <a rel="nofollow" href="https://www.r-bloggers.com/search/tutorial" title="R tutorials">tutorials</a> on topics such as: <a rel="nofollow" href="https://www.r-bloggers.com/search/data%20science" title="Data science">Data science</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/Big%20Data" title="Big Data">Big Data, <a rel="nofollow" href="https://www.r-users.com/" title="R jobs">R jobs</a>, visualization (<a rel="nofollow" href="https://www.r-bloggers.com/search/ggplot2" title="ggplot and ggplot2 tutorials">ggplot2</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/boxplot" title="Boxplots using lattice and ggplot2 tutorials">Boxplots</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/map" title="Maps and gis">maps</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/animation" title="Animation in R">animation</a>), programming (<a rel="nofollow" href="https://www.r-bloggers.com/search/RStudio" title="RStudio IDE for R">RStudio</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/sweave" title="Sweave and literate programming">Sweave</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/LaTeX" title="LaTeX in R">LaTeX</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/SQL" title="SQL and databases">SQL</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/eclipse" title="Eclipse IDE for R">Eclipse</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/git" title="git and github, Version Control System">git</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/hadoop" title="Large data in R using Hadoop">hadoop</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/Web+Scraping" title="Web Scraping of google, facebook, yahoo, twitter and more using R">Web Scraping</a>) statistics (<a rel="nofollow" href="https://www.r-bloggers.com/search/regression" title="Regressions and ANOVA analysis tutorials">regression</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/PCA" title="principal component analysis tutorial">PCA</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/time+series" title="Time series">time series</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/trading" title="finance trading">trading</a>) and more...
<img width="1" alt="" src="http://feeds.feedburner.com/~r/RBloggers/~4/XABzm2fg3sM" height="1"></a></div>