cytomining
Adding DOI to the code base
File location of the documentation
Pycytominer README.md
Documentation issue
Adding a codebase DOI into Pycytominer as suggested by the reviewer.
"... and to assign a DOI to the code base."
Suggested solution
Adding a codebase DOI and including the Zenodo DOI badge in the README file.
FWIW, we should point to the archived zenodo reference somewhere (i can also see the argument to not include it anywhere in the README to reduce clutter/confusion), but I would discourage highlighting the badge given our preference to cite the paper over the archived code
Good point. Do you think it would be better to create a DOI and include it in the manuscript, or should we skip the DOI and simply inform the reviewer that we'd prefer our code to be cited directly from the paper?
Personally, I prefer having the paper cited, but if having a DOI is essential for good software practices, we could consider adding it to the manuscript. My concern, however, is that people might choose to cite the DOI instead of the paper.
What are your thoughts?
We should mint a DOI with zenodo, but not reference it in the README to avoid citation confusion. Minting with zenodo means that pycytominer will exist independently of GitHub, which is a good thing
I like the practice of having both the paper and code having independent DOIs. The paper is a static description of pycytominer at a given point in time, but pycytominer will continue to evolve and grow over time. Hopefully folks will cite both ;)
I’ve been thinking about this, but I have one question: how often is “Cite this repo” actually used in the field? I was considering whether we should include the software DOI in the CFF file, while keeping the badge in the README for citing the manuscript. Since we want more people to cite the manuscript rather than the repository itself, placing the software DOI in the CFF file seems more appropriate. We could also update the Citing Pycytominer section in the README to include a direct link to our manuscript
What do y'all think?
I think adding the software DOI somewhere it can be easily found is a good idea. This would help us follow FAIR practices (making it "Findable"). The GitHub integration with CITATION.cff may yet change in the future. That said, relying on the format itself instead of GitHub's preferences could help us in the long run.
Maybe we could use "credit redirection" to help address some of this issue's discussion: https://github.com/citation-file-format/citation-file-format/blob/main/schema-guide.md#credit-redirection . That section of the CITATION.cff observes that sometimes we want to cite a different artifact, such as a paper.
It seems like we might have accomplished this issue with recent changes. @axiomcura - do you have any thoughts here (should we close)?