0008 - Publication strategy and guidelines

[mkhorton]

I think we're overdue to have a conversation about this. I've added more details in the document in this PR: please read this first.

This issue is not intended to discuss any one specific code, but just to talk more broadly on what we can do to incentivize publications and maintain accountability (e.g. make sure publications are actually finished and published, since software papers are often one or two spots away from the top of the "to do" list; we've had a few sit in draft, or sit on arXiv).

I'm adding a public note that @shyuep, @janosh and myself have been planning a new pymatgen paper. We have heard loud and clear from the pymatgen developer community that this is something that is desired. More specifics to follow on this, but I would prefer not to discuss that here, and not to discuss any other specific paper in this issue. This issue is intended for overall strategy only.

[JaGeo]

Thanks for this! This reads very good!

I would like to directly add an additional suggestion: in many EU countries, software publications such as zenodo now also count as publications. It very much helps if the release notes include detailed information on the contributors (similar to what is now done for every pymatgen release). Maybe, we could also add some best practices in this regard. I am now adding every major development to our internal collection of publications (e.g., https://opus4.kobv.de/opus4-bam/frontdoor/index/index/start/10/rows/10/sortfield/score/sortorder/desc/searchtype/simple/query/george+janine/doctypefq/researchdata/docId/57569).

[shyuep]

I would also add that ultimately, those who want a software paper should take charge and write it. Saying it is priority no. 100 is not really a valid excuse. If someone wants the recognition and attribution, they can make it happen rather than wait for other people to make it happen for them.

[JaGeo]

While I agree that someone has to put in the work, it is good to know for new and maybe even old developers that these options exist and that they can work towards a (new) software publication. Thus, writing it down makes asking for publications much easier as this kind of engagement might be even welcome (by MP, or individual maintainers).

[mkhorton]

Following meeting, some concrete suggestions for including in a decision:

• Include standard language in documentation for how to cite code. This should include citation for a publication, but also a Zenodo citation for the specific version of the code.
• All codes should have a Zenodo citation that can be automatically updated from GitHub contributors.
• When a paper is being written, maintainers are expected to (a) pro-actively contact contributors for inclusion in a paper, (b) place a public note in documentation that a paper is being prepared. Intent is to make sure people are not accidentally omitted.
• We should have a call-out that contributions are not limited to just writing code, and might include other tasks. Authorship decisions are at the discretion of code maintainers.
• Project maintainers are expected to consider updated publications for projects that are maintained and improved over long term, especially in cases where the original publication no longer accurately describes the code, or new contributors are not represented.