Anonymous R packages on CRAN or Github to accompany a blinded expert review of the submitted manuscripts

Is there a way to anonymously exchange an R-package that will work on Unix, Mac and / or Windows (preferably all 3 and easily have it on CRAN)?

The presence of the R package on CRAN, so that the analyzes can be reproduced, and the methodology can be demonstrated and shared, can be a great incentive to review the manuscript presented in a scientific / statistical journal (in my opinion and experience).

If this magazine requires blinded feedback, how can I share the R package in such a way that it monitors the viewing (traditionally, my name and email address are listed in the DESCRIPTION file to unleash the review)?

I thought of the following options, all of which have disadvantages:

  • Go through the entire CRAN submission process with an alias (fake name and email address) without using github (my github username is my last name). After the review has not been sealed / paper accepted, change the emission information to the correct information. I am not sure of the etiquette of this and how the CRAN policy will consider this practice.
  • Zip up R package without the participation of CRAN or Github and trust the reviewer is interested and is able to just install it from a source in unix. There is a big difference between this and the ability to enter install.packages() and library() into a system that the reviewer is familiar with, and manually creating and enabling zip for all platforms is tedious.
  • Do not make the packet, just send the code snippets and data and indicate in the manuscript that the R packet appears (which is a weaker expression than "here is the R packet that is already on the CRAN", another drawback listed in clause 2).

I mentioned CRAN and Github because I am most familiar with these repositories. I am open to other solutions.

+5
source share
1 answer

There is no need to have a packet on CRAN, 1 at all, and not to send anonymous packets to CRAN . Such a view would be a big problem for CRAN in terms of maintainability. CRAN is simply not the right platform for this.

Github has similar problems, but in principle, you can simply create a separate Github account without providing identifying information.

However, this simply poses a more serious problem: how is your code not really identified? More generally, the whole idea of ​​a double-blind peer review is exacerbated by research identifiability issues. I do not think this is a good solution (especially using a code review, but even in general), where the research is anonymous. Thus, I do not think that it is worth spending energy trying to make anonymous representations of the code, to the detriment of the quality of software (service).

In cases where a double blind anonymous peer review is required, the best option at present is to transfer the code to a service that allows an anonymous archive, such as Figshare, or send the archive as additional material to the journal. The reviewer should not expect simple

 install.packages(path_to_file, repos = NULL, type="source") 

... otherwise they may not be qualified to view the code in any way.


1 Actually, this is not even advisable (on the contrary, I find that cluttering CRAN is quite counterproductive, although CRAN is “comprehensive” in its own name, ideally all its contents should be in the form of correctly used packages, in other words: quality, not quantity).

+11
source

All Articles