Closed mpadge closed 2 years ago
In that case, it would mean stopping the Zenodo DOI requirement. I am not sure what is really useful.
Note that with the recent pkgdown release all sites have a citation link in the navbar https://docs.ropensci.org/magick/ with citation info created from DESCRIPTION in the absence of a CITATION file.
Yes, precisely as stated by @jhollist too. I'm happy to close this issue with no action then, but mostly wanted to document us having thought about this in relation to the automated checks. Thanks!
I'd be in favor of some clarifying language in the Dev Guide on this. Is a CITATION file a requirement? Is a Zenodo DOI a requirement. As you said, @mpadge it is implied in the DevGuide. I couldn't find anywhere in the Dev Guide that says a Zenodo DOI is required. If I get around to it I can draft something up, but next couple of days are busy for me...
Maybe I'm out of date here, but I'm failing to see the connection between CITATION and Zenodo. Zenodo gives you a DOI every time it takes a snapshot. If we're using the GitHub integration option, it takes a snapshot every time you make a "release" on GitHub, and then your DOIs are automatically versioned as well. In the past this has never needed a CITATION file to work, and I don't see any indication that it requires that now. AFAIK, Zenodo doesn't use the information in the CITATION file either, it uses the information in a .zenodo.json
file, or else the information from GitHub, or else you can manually correct the metadata. In https://help.zenodo.org/#versioning I see some discussion that they might support codemeta.json (they were with us in designing the codemeta spec in 2016 after all), and some mention of the citation .cff
spec.) Sorry maybe I'm missing something.
It's not clear how it would even use the information in a CITATION file -- specifically, such information may very well include one or more DOIs to another product. An R package CITATION file will often list one or more papers the package authors want you to cite. When we also archive the package on zenodo, the package itself gets it's own DOI. An R user who uses the citation()
function in R will thus be told to cite the paper, but if instead, they see the DOI for the package and ask DataCite to mint a citation string, they'll get a citation to the Zenodo record instead. That citation will be tracked by DataCite but not by CrossRef, TR, etc, and won't help the author's H-index or any of the other bizarre metrics we now load on this process anyway, but I digress.... I'm all for zenodo archiving with good metadata, but I think that's a completely independent thing from CITATION files. )I also think that software heritage should be considered a valid long-term archive alternative, even though it is not associated with a DOI, since I am not convinced that DOIs for software are improving either the goal of discovery, archival preservation, or citation per say, but that's another thread sorry) I think we create a rather confusing landscape around citation here with all these files....
Apologies for whining, not trying to blame anyone!
From what I had understood, the Zenodo DOI was useful to store in CITATION but maybe not then if you think a citation of software with no Zenodo DOI is not worth less?
I'm tending very strongly towards Carl's opinions here, and would prefer to drop requirements for a CITATION file. Zenodo is indeed useful to store in a CITATION file, but shouldn't be a requirement. Most importantly in this context, arbitrarily adding a CITATION file at time of submission really does nothing other than junk up a repo. Generic versions of those files are nothing other than the output of the citation()
function, but hard-coded and therefore disadvantageous because can quickly become de-synced with changes to DESCRIPTION files.
My suggestions would be:
pkgcheck
- If your package does not yet have a CITATION file, you can create one with
usethis::use_citation()
, and populate it with values generated by thecitation()
function.
Thoughts?
Sounds good, I'll make a PR to the dev guide
Cool, and then I'll disable the check here. Thanks!
To quote @cboettig here:
@maelle what do you think? The DevGuide pretty much implies that this is required (albeit indirectly), and that check merely follows that. Should we both
pgkcheck
?@cboettig Feel free to opine further here too :smile: