First slide of the talk
Abstract
We benefit from others’ work on R and also by shared packages and for our programming tasks. Occasionally we might generate some piece of software that we want to share with the community. Usually sharing our work with the R community means submitting a package to an archive (CRAN, Bioconductor or others). While each individual archive has some rules they share some common principles.
If your package follows their rules about the submission process and has a good quality according to their rules it will be included. All submissions have some common sections: First, an initial screening; second, a more profound manual review of the code. Then, if the suggestions are applied or correctly replied then the package is included in the archive.
On each step some rules and criteria are used to decide if the package moves forward or not. Understanding what these rules say, common problems and comments from reviewers will help avoiding submitting a package to get it rejected. Reducing the friction between sharing our work, providing useful packages to the community and minimizing reviewers’ time and efforts.
Looking at the review process of three archives of R packages, CRAN, Bioconductor and rOpenSci, I’ll explain common rules, patterns, timelines and checks required to get the package included, as well as personal anecdotes with them. The talk is based on the post analyzing reviews available here: https://llrs.dev/tags/reviews/
The abstract I presented to be accepted was:
We benefit from others’ work on R and also by shared packages and for our programming tasks. Occasionally we might generate some piece of software that we want to share with the community. Usually sharing our work with the R community means submitting a package to an archive (CRAN, Bioconductor or others). While each individual archive has some rules they share some common principles.
If your package follows their rules about the submission process and has a good quality according to their rules it will be included. All submissions have some common sections: First, an initial screening; second, a more profound manual review of the code. Then, if the suggestions are applied or correctly replied then the package is included in the archive.
On each step some rules and criteria are used to decide if the package moves forward or not. Understanding what these rules say, common problems and comments from reviewers will help avoiding submitting a package to get it rejected. Reducing the friction between sharing our work, providing useful packages to the community and minimizing reviewers’ time and efforts.
Looking at the review process of three archives of R packages, CRAN, Bioconductor and rOpenSci, I’ll explain common rules, patterns, timelines and checks required to get the package included, as well as personal anecdotes with them. The talk is based on the post analyzing reviews available here: https://llrs.dev/tags/reviews/
I received excellent feedback from the reviewers and I got a full talk (I asked for a poster because I was nervous to present to a big audience).
This talk also received one of the Accessibility Awards.
