00:20:11 Micha Moskovic: INSPIRE is not tracking software citations ... for now 😉 00:20:33 Alexander Held: @Liz I wanted to check whether I understood your experience with HSF: it was hard to get projects reach the standard that you can clone and build a project with the provided instructions without having to debug things to get things working? 00:21:57 Daniel S Katz: My comments were based on a subset of RSEs I chatted with in slack yesterday - it's dangerous to assume too much agreement with this, as the RSE community itself is quite diverse, with people who like writing papers on one side, and people who object to it on the other side 00:30:55 Daniel S Katz: I think that adding metadata in the repo (eg citation.cff or zenodo.json) would let zenodo automatically build the author list from that file 00:31:04 Matthew Feickert: it does 00:31:17 Matthew Feickert: I'll mention in my talk this is very easy now 00:31:18 Jim Pivarski: Zenodo does build an author list from CITATION.cff. That's true. 00:33:41 Alexandros Ioannidis: Indeed (the old-style ".zenodo.json") and CITATION.cff is the way to go for maintaining metadata that gets picked up by Zenodo, I can understand though the friction that comes from still having to do the work. 00:34:59 Matthew Feickert: there's no work if you connect the account 00:35:37 Alexandros Ioannidis: I mean the work for keeping CITATION.cff up-to-date :) 00:35:52 Eduardo Rodrigues (he/him): Agreed. It takes minutes to set things up and you're largely done for many subsequent releases until you need to update to add an author that is above threshold as contributor (probably the main reason for an update). 00:37:03 Matthew Feickert: Alexandros maybe you can comment in my talk what you mean by work of keeping it up to date? Would be relevant to the discussion there and I'd like to know more 00:38:13 Alexandros Ioannidis: I think what's important is automation tools that fit as part of CI/CD and regular release workflows. Many projects spend a lot of effort already on their release process (bump versions, generate changelog, update CONTRIBUTORS file, etc.). Keeping CITATION.cff up-to-date in my view fits this process. 00:39:06 Alexandros Ioannidis: (snoozing, since it's more relevant for your talk :) ) 00:41:28 Mark Neubauer: I had the same comment as Eduardo in terms of reproducible research. If a ROOT but is found in some version, we need to know what version of a key software package is used in a publication 00:42:33 Graeme A Stewart: Thanks everyone for also keeping the live notes up to date with your comments: https://docs.google.com/document/d/1AN-Kv59kkz3vyVLImeA3nehcyUfM2WEGnaCNBJRy7q4/edit?usp=sharing 00:42:35 Attila Krasznahorkay: But as we keep coming back to it: If you need actual reproducibility, that's up to something like RECAST to do. What we discuss now to me is all about recognition. Not about reproducibility... 00:42:38 Mark Neubauer: Maybe this is the internal duty of the experiments (code, containers, .. for a published result), but citations would help here and “crowdsource” the consideration of impact of software “features” on physics publication 00:43:12 Mark Neubauer: Yes, Attila - my comments after yours was coming around to that point 00:43:26 Daniel S Katz: software citation is not sufficient for reproducibility, but it can be helpful as a step along the way 00:43:32 Mark Neubauer: That software citation is of limited use in reproducibility 00:44:35 Daniel S Katz: From the 2016 software citation principles paper: "Reproducibility: Citation of specific software used is necessary for reproducibility, although not sufficient. Additional information such as configurations and platform issues are also needed." 00:45:08 Daniel S Katz: Also from that paper: "The data recorded for reproducibility should also overlap the metadata recorded as part of software citation. In general, we intend the software citation principles to cover the minimum of what is necessary for software citation for the purpose of software identification. Some use cases related to citation (e.g., provenance, reproducibility) might have additional requirements beyond the basic metadata needed for citation" 00:58:05 Andy Buckley: A few mins to do it once you know how the system works, but a bit more to figure it out the first time, I suspect. And there are a lot of similar config tweaks for GitLab/Hub, Zenodo, etc. etc. so these things do turn into hours in the end, but the point is taken that they are not individually big! 01:10:55 Daniel S Katz: FYI (re assessment policy): https://future-of-research-software.org is also developing an Amsterdam declaration on research software that will also talk about credit and citation, at least at a high level 01:11:13 Amy Roberts: I use software DOI citations all the time in my grant applications :) 01:11:21 Mark Neubauer: Me2! 01:22:47 Daniel S Katz: Re FAIR for research software, see https://doi.org/10.1038/s41597-022-01710-x for a paper about the principles, and https://doi.org/10.15497/RDA00068 for the principles themselves 01:23:20 Andy Buckley: HepData itself uses Rivet's InspireID -> analysis name (and hence a link URL) JSON https://rivet.hepforge.org/analyses.json Could that mechanism also be used to link to analysis preservations directly from Inspire papers? 01:27:04 Daniel S Katz: @Micha - the software citation implementation group would be happy to answer any questions that it can help with - please consider it a resource if that seems useful 01:30:22 Alexandros Ioannidis: The INSPIRE HEP community on Zenodo: https://zenodo.org/communities/inspire 02:05:49 David Chamont: I am surprised that Software Heritage (https://www.softwareheritage.org/) was refered for the first time (in the elsevier talk) ! 02:07:11 Matthew Feickert: I think it might be partly because Software Heritage does all the work for you. You don't need to seek them out, they search and find you 02:10:09 David Chamont: They do provide some sort of Persistent IDentifier (PID). I wonder if they can be used as some sort of DOI in citations, and if this make useless for developers to drop their code in Zenodo. 02:11:20 Daniel S Katz: it's a very long and complicated PID compared to a DOI, but has some added value 02:11:44 Matthew Feickert: I got to be the reviewer for this publication. :) They did a great job! 02:15:34 Daniel S Katz: yes, the E in JOSE is education 02:28:40 Alexandros Ioannidis: Correct, we only provide out-of-the-box integration with GitHub. 02:29:24 Andy Buckley: It'd be good to have integration with GitLab, particularly given that's the repo hosting that CERN uses 02:34:52 Graeme A Stewart: And the IN2P3 Gitlab 02:35:15 Andy Buckley: Aha, thanks! 02:40:09 Daniel S Katz: I must be the only one here who is wondering what UFOs are in the context :) 02:40:13 David Chamont: Thanks for the answers. Very clear. 02:40:26 Micha Moskovic: @Daniel same here :) 02:41:12 Matthew Feickert: UFO = Universal Feynman Output 02:41:24 Mark Neubauer: Slide 3 02:41:43 Matthew Feickert: *FeynRules, my bad 02:44:12 Zach Marshall: and worse, the _trunk_ of the repository… 02:52:22 Andy Buckley: Has this been discussed with the FeynRules (db) authors? I suspect they might support a more competent tech than a wiki page, but of course don't want the two dbs to be in competition 02:52:42 Zach Marshall: 100% agree with Andy 🙂 02:53:57 Andy Buckley: The open question then is whether your metadata db is more long-term stable than Zenodo, no? 02:54:02 Andy Buckley: Haha! 02:54:06 Andy Buckley: Verbatim 02:55:35 Andy Buckley: It sounds very useful, but discussion on some of these details and including the FR authors would be a great next step. Thanks 03:21:58 Daniel S Katz: thanks again everyone!