PUBLIC version control

[mih]

At present, we ask for "a version control system". But I think it is important to add the notion of "who may access it". Maybe we cannot make it mandatory that it is fully open from the get go, but I believe we should (at least) suggest to have the VCS fully accessible at the time of publication. This is also related to the "persistent URL" issue. There isn't much of a benefit of a DOI if the resource isn't public. Not sure of zenodo would even allow for private repos.

[sje30]

Thanks Michael. I've made a brief mention of this. But to keep this ticket open, we have the wrinkle that I don't know how to solve smoothly yet.

If you have a private repo, and plan to make it public on publication, how do you share the repo with reviewers before it is published? There is no way in github (ast least when I asked Arfon at gh a few months ago) to get anon RO access to private repos e.g. with a salted link.

I can think of a few solutions, none of which are ideal:

1. Upload the master.zip file from github when you submit.
2. Create a new (temporary) account on github, add them to your private repo. Share these account details with the editors/reviewers and hope they don't make any commits!
3. Make the repo public at the time of submission, not time of publication.

I've taken approach 3 recently.

@benmarwick - what's your advice on this matter?

[mih]

I agree that 3) is good -- doing the same here. However, if you have a git repo with all code, it is trivial to submit a snapshot in a zip ( should be your first option). Hence, 1) seems to be the low hanging fruit that imposes no additional technical difficulties.

Michael On Jul 20, 2015 1:34 PM, "Stephen Eglen" notifications@github.com wrote:

Thanks Michael. I've made a brief mention of this. But to keep this ticket open, we have the wrinkle that I don't know how to solve smoothly yet.

If you have a private repo, and plan to make it public on publication, how do you share the repo with reviewers before it is published? There is no way in github (ast least when I asked Arfon at gh a few months ago) to get anon RO access to private repos e.g. with a salted link.

I can think of a few solutions, none of which are ideal:

1.

Upload the master.zip file from github when you submit. 2.

Create a new (temporary) account on github, add them to your private repo. Share these account details with the editors/reviewers and hope they don't make any commits! 3.

Make the repo public at the time of submission, not time of publication.

I've taken approach 3 recently.

— Reply to this email directly or view it on GitHub https://github.com/sje30/sharing-report/issues/8#issuecomment-122855405.

[benmarwick]

Currently what I do is deposit the github repo in figshare (figshare has a tool that grabs the zip), then from figshare get a 'private sharing link', and include that URL in the submitted manuscript so editors and peer reviewers can see the figshare repo. Then when the paper is accepted, I make the figshare repo public and update the manuscript with the DOI to the figshare repo. In the figshare repo metadata is the URL to the github repo as the 'development' version, while the figshare repo is described as the 'stable' version that matches the paper. Here's a description of the figshare private URL: http://figshare.com/blog/figshare_new_features_Get_DOI_or_private_sharing_link/135

Figshare has it's own version control, so it's possible to update the same repo from github multiple times during the peer review and revisions process, which is quite handy.

Since we're recommending DOIs, using figshare like this seems like a good fit for our paper :)

[sje30]

Great, thanks Ben. Perhaps this is too detailed for our paper, but at least we can recommend a few suggestions depending on people's preferences.

[benmarwick]

Yes, agreed, it's not suitable for the paper itself. We could consider do this with our paper as part of 'leading by example', and perhaps mention this workflow in a readme file in the paper repo?

[jbpoline]

That's a great idea. Let's do that ! Steve, you probably have a figshare account otherwise it's trivial to make one.