Update citation recommendations: explain how to cite PISM's versions archived by Zenodo

[ckhroulev]

We should update PISM's documentation to recommend

• citing a PISM version archived by Zenodo if a study citing it was performed using an unmodified PISM release
• archiving modified PISM code on Zenodo, then citing it and the PISM release it was based on if a study was performed using a customized version of PISM

... in addition to citing papers currently listed in ACKNOWLEDGE.rst.

[bueler]

Each PISM release is now archived at Zenodo? Nice! (Maybe this is proposed only.) The release info at https://github.com/pism/pism/releases will/should contain a Zenodo link?

[bueler]

I see that the zenodo links already exist. The release statements should contain these too, right?

[ckhroulev]

Each PISM release is now archived at Zenodo? Nice!

Yes, starting from 2.0.

The release statements should contain these too, right?

Hmm. I'm not sure. The DOI for a particular release does not exist when release notes get written, so this would require manually updating release notes after Zenodo generates the DOI. It's not hard, but I don't know if it's necessary.

[bueler]

Zenodo DOIs lead to a .zip snapshot of the source, which (I think) we would want to discourage for almost all users. (In theory there is someone who wants to reproduce a result and never use PISM again?) Presumably support is better if people are getting versions from git. How about just the root zenodo DOI at the end of each release statement?: "Follow https://doi.org/10.5281/zenodo.1199019 to the zenodo DOI for this release."

[bueler]

I don't really think the invention of zenodo helps humanity very much. Just putting repository urls into publications, and stating version tags, is much more effective for actual "reproducibility" purposes. But you are dealing with zenodo as it is. 😄

[ckhroulev]

Zenodo DOIs lead to a .zip snapshot of the source, which (I think) we would want to discourage for almost all users.

I don't have a problem with using .zip archives from Zenodo to install PISM. (This reminds me that I need to make a small change to ensure that PISM version info is properly recorded in this .zip and binaries built using sources in it.)

How about just the root zenodo DOI at the end of each release statement?: "Follow https://doi.org/10.5281/zenodo.1199019 to the zenodo DOI for this release."

Sure!

Just putting repository urls into publications, and stating version tags, is much more effective for actual "reproducibility" purposes.

I disagree.

• Zenodo is backed by CERN and is likely to outlast an average repository. (Recall that Gna! is down and an URL pointing to it is useless.)
• Unlike URLs and version tags, DOIs correspond to immutable snapshots. This immutability is also backed by an authority or at least a third party, which I think is great. (Even if a repository still exists, there is no guarantee that its contents did not change. Version tags can be deleted or rewritten.)

Just the other day I spent way too much time fixing URLs pointing to UMT's SeaRISE wiki and P. Huybrechts' old web page. Luckily the SeaRISE wiki is now archived on Zenodo, but I have to rely on web.archive.org to maintain our EISMINT and ISMIP-related stuff. I wish I didn't.

I wish the GitHub-Zenodo integration setup archived a snapshot of the repository including commit history up to the tag corresponding to a release (instead of a snapshot of the contents of a repository), but that's a minor thing.

[bueler]

@ckhroulev That makes sense. I guess I thought that helping users running from a .zip was an issue, but in practice I guess it is not. I am confident github will last a lot longer than GNA. 😜

[ckhroulev]

@bueler To add to the confusion: the name "Gna!" and the domain gna.org got recycled.

[bueler]

@ckhroulev Yikes! "How the mighty have fallen!" would hardly fit ... gna was never mighty.