Merge pull request #8 from materialsproject/publications

0008 - Publication strategy and guidelines

decisions/0008-publication-strategy-and-guidelines

@@ -0,0 +1,62 @@
+# Scope of emmet document models
+
+## Context and Problem Statement
+
+Regular publications are important for several reasons, including:
+* An additional method to communicate capabilities of codes with the community.
+* Career advancement for individual contributors.
+* Increased confidence in methods when a publication has been peer-reviewed.
+* An additional method to track usage of a code, specifically when that usage has lead to a scientific advance.
+* Motivate and incentivize contribution to codes from new contributors.
+
+It is expected that **publication decisions will primarily always be the responsibility of lead developers.** 
+However, it might be useful to formalize some guidelines for best practices.
+
+## Decision Drivers
+
+TBD
+
+## Considered Options
+
+### Proposed Guidelines
+
+We could propose a guideline document that includes the following main points:
+
+1. We encourage publication of software papers.
+   Publication and organization of a software paper is the responsibility of the lead developer(s) of that
+   software package. The following are guidelines only.
+2. A paper should be written or planned by the time an open-source code is used either in published scientific
+   research or used on the production Materials Project website.
+3. A distinction can be made between more focused codes (e.g., a single feature, unlikely to see extensive
+   future development) and more foundational codes (e.g., expects lots of future development or contains a
+   new scientific formalism). The former might be more appropriate for a brief paper in a journal such as JOSS.
+4. To acknowledge that the initial set of authors will inevitably be incomplete over the lifetime of the code,
+   two strategies are suggested:
+   a. A Zenodo citation that is continuously updated with all contributors and includes release notes specifying individual contributions.
+   b. "Update" papers, on a frequency that is best determined by the circumstances of an individual code.
+5. Paper authorship should be as inclusive as possible, recognizing contributions of not just new features,
+   but significant bug fixes, documentation improvements, and other meaningful effort. No contributions should
+   be taken for granted.
+
+## Decision Outcome
+
+We recommend the following specific actions within each supported code:
+
+1. Include a "How to Cite" section in the README file that contains a link to relevant publications (if any) and/or a BibTex entry
+2. Ensure that the repo is connected to Zenodo so that DOIs are minted with each public release
+3. Whenever a publication is in the works, advertise it in the project README and/or via a pinned issue and invite contributions from community members.
+
+The atomate2 repository provides a good example of implementing this policy. ([README ](https://github.com/materialsproject/atomate2?tab=readme-ov-file)and [issue](https://github.com/materialsproject/atomate2/issues/750))
+
+These actions were unanimously approved at the 01-13-25 MPSF Steering Committee meeting.
+
+## Implementation Plan
+
+All codes are requested to review their READMEs and Zenodo settings.
+
+- [ ] `pymatgen`: README already done; needs Zenodo integration.
+- [x] `atomate2`: Already implemented.
+- [ ] `emmet`: needs README and Zenodo integration.
+- [ ] `crystal-toolkit`: README already done; needs Zenodo integration.
+- [ ] `jobflow`: README already done; needs Zenodo integration.
+- [ ] `maggma`: needs README and Zenodo integration.