Anonymous R packages on CRAN or Github to accompany blinded peer review of submitted manuscripts [closed]

Question

Is there a way to share R-package anonymously that will work on Unix, Mac, and/or Windows (preferably all 3 and with the ease of having it on CRAN)?

Having an R package on CRAN so that analyses can be reproduced and methodology can be demonstrated and shared can be a big boost to the review of a manuscript submitted to a scientific/statistical journal (in my opinion and experience).

If that journal requires blinded reviews, how can I share the R package in a way that keeps the review blinded (traditionally, the DESCRIPTION file lists my name and email address, which would unblind the review)?

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

1. Go through whole CRAN submission process with a pseudonym (fake name and throwaway email account) without using github (my github username is my last name). After the review is unblinded / paper is accepted change the throwaway information to the correct information. I'm uncertain of the etiquette of this or how CRAN's policy would deem this practice.
2. Zip up R package with no involvement of CRAN or Github and trust the reviewer is interested and capable enough to install it from source on unix. There's a big difference between this and being able to type install.packages() and library() on the system the reviewer is familiar with, and manually creating and including zips for all platforms is tedious.
3. Don't make a package, just send code snippets and data and state in the manuscript an R package is forthcoming (which is a weaker statement than, "here's the R package that is already on CRAN"; another drawback is that listed in item 2).

I've mentioned CRAN and Github because I'm most familiar with these repos. I'm open to other solutions.

Batty

if there is no compiled (C/Fortran) code, put it on Github anonymously and use the drat package – Handsome

I'm voting to close this question as off-topic because it's a question about package distribution, not programming (also quite susceptible to opinion-based answers ...) – Handsome

@BenBolker I find it hard to imagine that software distribution isn’t intrinsically related to software development. As such, it is related to programming. I agree with your point about opinions (example: my answer). But then again my answer also attempts to actually answer the question helpfully. – Syndesmosis

According to the criteria laid down in stackoverflow.com/help/on-topic this question is off-topic indeed. However, I find this is an interesting question. So, what is the legitimate place to put this question? – Dishwasher

Answer 1

There’s no need at all to have the package on CRAN,¹ and there’s no way to submit packages anonymously to CRAN. Such a submission would be a big problem for CRAN in terms of maintainability. CRAN is simply not the correct platform for this.

Github has similar issues but in principle you could just create a separate Github account without providing identifying information.

However, this just sidesteps a bigger issue: How non-identifiable is your code really? More generally, the whole idea of double-blinded peer review is dogged by issues of identifiability of the research. I don’t think there’s a good solution (especially involving code review, but even in general) where the research is submitted anonymously. As such, I don’t think it’s worthwhile spending energy trying to make code submissions anonymous, to the detriment of software (maintenance) quality.

In cases where double-blind anonymous peer review is desired, the currently best option is to submit the code to a service that allows anonymous archival, such as Figshare, or submit an archive as supplementary material to the journal. It should not be a stretch to expect the reviewer to perform a simple

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

… otherwise they may not be qualified to review the code anyway.

---

¹ In fact this isn’t even desirable (on the contrary, I find the cluttering of CRAN quite counter-productive; though “CRAN” has “comprehensive” in its name, ideally all its contents should be in the form of properly usable packages; in other words: quality, not quantity).

Syndesmosis

Please consider editing the (otherwise good and helpful) answer and removing the opinionated ranting about CRAN in the first paragraph. Put that in another question, on another stack exchange site, preferably on another planet :) The rest is good and worthy of an upvote, but the whole currently does not deserve one (yet). – Evocation

@Dirk It’s fundamentally a technical aspect that’s generally agreed on, and it explains why CRAN is the wrong place (even if it is — in the R community only! — a minority view). I’ll relegate it to a footnote though. – Syndesmosis

I'm sure the CRAN maintenance team would welcome your offer to review, test, and validate all submitted packages! Seriously, do you have any idea how much work that would be? There's a reason that, e.g., Mathworks, charges so much for commercial toolboxes. – Dobrinsky

@Konrad, thanks for the edit. It now earned an (easy) upvote. – Evocation

@CarlWitthoft That’s my point exactly: if only actually useful packages were submitted to CRAN, the maintainers’ jobs would be much easier and they could spend their time in more useful pursuit. As it is, lots of rubbish gets submitted and requires curating. I’m not suggesting the maintainers do more work (in sorting out bad quality), I’m suggesting submissions should be encouraged less by the community than they currently are. – Syndesmosis