feat: add CITATION.cff #1994
feat: add CITATION.cff #1994
Conversation
| - family-names: Daniel Brandenburg | ||
| - family-names: Dhevan Gangadharan | ||
| cff-version: 1.2.0 | ||
| date-released: '<replace with the actual release date>' |
There was a problem hiding this comment.
The intention behind this was to avoid people just including a reference without any version at all. If we put a real version here, then it would just go out of sync.
There was a problem hiding this comment.
I assume if we omit, Zenodo will fill this in?
Looking at https://github.com/scikit-hep/uproot5/blob/main/CITATION.cff
they put date-released for the original release date and version is not specified.
Each version on Zeonodo is already provided with an unique DOI, we don't need to make a CITATION.cff to address that.
There was a problem hiding this comment.
My concern is that people won't (only) go to zenodo for the citation, but copy it directly from GitHub, see https://github.com/eic/epic/ and the "Cite this repository" menu on the right sidebar. That's based purely on what's inside the cff file.
There was a problem hiding this comment.
So we should be removing the cff file from eic/epic and replacing it with a Zenodo link in the README?
There was a problem hiding this comment.
That's what we have here... and it isn't working. I think having the "Cite this repository" is a better solution than expecting people to know they can cite zenodo. They (especially now) think of zenodo as a place for internal documents.
| repository-code: https://github.com/eic/EICrecon | ||
| title: 'eic/EICrecon: <replace with the actual version>' | ||
| type: software | ||
| version: '<replace with the actual version>' |
| - family-names: Peter Steinberg | ||
| - family-names: Minho Kim | ||
| - family-names: Daniel Brandenburg | ||
| - family-names: Dhevan Gangadharan |
There was a problem hiding this comment.
I was wondering about that too. It's related to the problem with the versions. If we could automate our version release workflow and include a download of a new CITATION.cff, then we can get away from this. Otherwise, I am just tempted to keep it as is, and replace it maybe on demand (we can add a comment line to the file) or on schedule. We could probably even do a scheduled job that downloads the file, checks for diffs, and opens a PR with the necessary changes. But that's all work...
There was a problem hiding this comment.
I guess, the assumption here, again, that we somehow track this better then Zenodo can. I don't quite understand how a job would source some better information (parse spdx headers?)
There was a problem hiding this comment.
You're overthinking the job. It would consist of curl https://zenodo.org/records/15880663/export/cff with some massaging :-)
There was a problem hiding this comment.
That's until Zenodo will start feeding you your own cff?
There was a problem hiding this comment.
Putting the curl in curl.
2 participants
Briefly, what does this PR introduce?
This adds a CITATION.cff file to the repository, linking to the zenodo entry, https://zenodo.org/records/15880663. Names autogenerated from zenodo. Unresolved names (i.e. just github username) removed.
What kind of change does this PR introduce?