from Hacker News

Citation File Format

by polm23 on 8/20/21, 3:08 PM with 35 comments

  • by benrbray on 8/21/21, 4:27 AM

    What is the advantage of this format over CSL-JSON [1] or BibTeX, which are already supported by software like pandoc? There is even a standard YAML citation format [2] used within YAML metadata for Markdown files, so I wonder why GitHub couldn't have chosen one of the existing options, lobbying the spec maintainers if any changes were needed.

    [1] https://citeproc-js.readthedocs.io/en/latest/csl-json/markup...

    [2] https://ymlthis.r-lib.org/reference/yml_reference.html

    [3] https://pandoc.org/MANUAL.html#citations

  • by avian on 8/21/21, 6:06 AM

    One thing I’m missing on GitHub is support for providing a citation for a journal paper about the software, not the software itself. It’s common to see something like “if you use this code, please cite this paper” in README files.

    There are many reasons why people put this into their READMEs, but it mostly boils down to the fact that paper citations affect various metrics, while citations of a GitHub repo mostly don’t matter.

    The citation file format does include a field for providing a list of extended references, but it seems that GitHub doesn’t support that.

  • by _Algernon_ on 8/21/21, 9:04 AM

    What does this do that a .bib file doesn't? It doesn't follow a standard which is made clear even by the creators themselves: "When you put a CITATION.cff file in the default branch of your GitHub repository, it is automatically linked from the repository landing page, and the citation information is rendered on the repository page, and also provided as BibTeX snippet which users can simply copy!"

    I don't see why they don't stick to the established standard and parse a CITATION.bib instead. It would be less complex, more friendly to the user, and less likely to cause lock-in.

  • by thenoblesunfish on 8/21/21, 7:13 AM

    This seems like a trap to make GitHub stickier. If something makes it harder to leave GitHub and host your code elsewhere, beware. In this situation, it seems safer to give people some BibTeX to copy-paste.

  • by Athas on 8/21/21, 8:45 AM

    I'm all for citing software. I still don't understand the guidelines for who to list as an author, though. In modern open source projects, you're going to have a very long tail of drive-by contributors. Some of these might not even touch the software itself, but merely fix a typo in the README or similar. Should the citation list all of these? As for myself, I'm very much in favour of crediting anyone for any contribution, no matter how small, but standard scientific practice is more exclusive. And what about names? When I look at the author list that Zenodo generates for my own main project [0], it's not only very long, but contains lots of online pseudonyms and even a few duplicates, due to differences in spelling or inclusion of middle names and such. My background is in the hacker community, so I think this is great, but I don't think a journal editor would agree.

    I could manually curate a list of the "main authors", which would be much smaller, but I'm not particularly enthusiastic about being the arbiter of when someone's contributions are major enough to become a "main author".

    [0]: https://zenodo.org/record/5062209

  • by cratermoon on 8/21/21, 5:01 AM

    oboy yet another citation format standard

  • by tannhaeuser on 8/21/21, 6:25 AM

  • by tejtm on 8/21/21, 6:03 AM

    How does (or should) this tie into that last tool they released that suggested snippets of of other peoples code ... copilot.

    When your code ends up with a morally equivalent section to something copilot suggested out of my repo should GH add my citation to your code?