Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How precise should citations of the code be? #343

Open
illorenzo7 opened this issue Nov 15, 2021 · 3 comments
Open

How precise should citations of the code be? #343

illorenzo7 opened this issue Nov 15, 2021 · 3 comments

Comments

@illorenzo7
Copy link
Contributor

Nick's latest pull request #341 made me think (again) about the citation standard for Rayleigh now that it has a stable release. There are three sub-issues in my mind:

A. Most (probably all) future publications will not actually be using v 1.0.0. That's because more pull requests will likely be merged soon, so unless everyone is super careful to run all production-level simulations directly from the v 1.0.0 executable, they will be using different versions. I think it would be good to instruct people to also include the shortened git hash (possibly with a hyper-link to the commit) in the actual paper citation if possible. I am imagining the citation would have two links: one to the DOI (v 1.0.0 or the latest stable release on Zenodo) and one to the specific git hash after v 1.0.0. Or, if the journal doesn't allow links people can still find the precise version of the code someone used. This would make all work fully reproducible. Is that possible and/or practical? @gassmoeller maybe you have some insight from aspect? (It might also be good to encourage people to use the same git hash for all simulations in a suite that's going to be published---I know I am guilty of continually doing fresh pulls and thus mixing and matching versions within a suite).

B. If people use their own branch, can we encourage them to make their Rayleigh fork publicly available---and then list the six-digit hash (hyperlinked to the citation) as above? Then the citation's DOI would still --> Zenodo stable release, but the hash (mentioned in part A) would point to their personal repository.

C. This is more of a practical issue, but I've recently noticed that Zenodo has a universal DOI for different versions of a project. Each new version will get its own DOI (v 1.0.0 = 10.5281/zenodo.5683601) but the latest version will always be this universal DOI (in this case 10.5281/zenodo.1158289). Should we encourage people to use the universal DOI in their citations? Otherwise we may have to update the citation instructions every time a new version is released.

@feathern
Copy link
Contributor

I agree that we should talk about this sometime in the next couple of months. I see what you mean.

@orvedahl
Copy link
Contributor

orvedahl commented Nov 16, 2021

This was discussed a bit during the CIG staff meeting earlier today. There are two categories of users: a) made modifications to the code and b) used the public code with no modifications. This leads to three cases when it comes to citations:

  1. you pull down the v 1.0.0 release (or any release that has a zenodo DOI) and use it without any modifications --- simply cite the zenodo release.

  2. you pull down the v 1.0.0. release, then some time later do a "git pull" to use the latest updates, but still have not made any modifications --- cite the zenodo release as well as the git hash that you used.

  3. you are using some kind of custom version of Rayleigh, i.e., your own fork, or the main release with your own modifications. You should obtain a zenodo citation for that version, and then cite the main Rayleigh code as well as your particular version. Lorraine will be working on some guidelines and/or instructions for this that will appear on the new geodynamics website.

@feathern
Copy link
Contributor

This is why we probably need a short JOSS paper. Ideally, there would be a common reference that's cited, as well as a version reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants