Pith. sign in

REVIEW 3 major objections 6 minor 31 references

On credit attribution and research software: A case study from lattice QCD

T0 review · 3 major / 6 minor · reviewed 2026-07-31 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A lattice QCD case study argues that long-term research software and conceptual work still fall outside fair authorship and integrity rules.

desk verdict A named lattice-QCD case study that makes the familiar software-credit problem concrete with public repos, GitStats, and German integrity procedure limits; useful as practice reflection, not as adjudication of the dispute. read the letter →

arxiv 2607.28444 v1 pith:JDM73ZWW submitted 2026-07-30 hep-lat

Alessandro Sciarra This is my paper · ORCID
classification hep-lat
keywords researchsoftwareauthorshipcreditattributionsustainabilitylatticeQCDintegritycareerpathsrewardsandincentives
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper uses a documented dispute in lattice QCD to show that traditional authorship and German research-integrity procedures do not reliably credit long-term research software and the conceptual extensions that grow out of it. The author recounts how analysis tools, simulation infrastructure, and a follow-up idea developed while finishing earlier joint work were reused in later papers while his authorship was withdrawn after an ombuds process that found no misconduct. He argues that software has become essential scientific infrastructure, yet career incentives still treat publication counts as the main currency, so people who invest years in maintainable code can lose both papers and positions. The piece is offered as a factual reflection meant to open community discussion, not as a re-litigation of the physics results. A sympathetic reader is meant to see why lattice QCD and similar fields may need explicit standards that treat sustained software contributions as first-class intellectual work.

What carries the argument

The documented case chronology itself: parallel arXiv uploads, reuse of shared analysis and management codebases (with contribution statistics), an initial authorship agreement later withdrawn, an OWID ombuds assessment of no wrongdoing, and subsequent institutional hand-offs that left broader governance questions unaddressed.

What would settle it

Independent comparison of the conceptual proposal paper with the later results paper, plus public commit histories of the cited codebases, showing either that the disputed ideas and software were not load-bearing or that equivalent credit was already given under clear prior agreement.

Watch

Extended reading notes

Core claim

In software-intensive lattice QCD, the combination of long-term software infrastructure, numerical strategy, and conceptual follow-on ideas can create authorship and priority disputes that neither conventional publication norms nor existing German ombuds and university misconduct channels resolve in a way that captures the full contribution, producing structural tension between open collaboration, software sustainability, and traditional credit.

Load-bearing premise

The author’s first-person timeline and contribution weights must be complete and accurate enough to support a general structural critique, even though he is a direct party and the confidential process found no wrongdoing.

Editorial extensions

If this is right

  • If the diagnosis is right, lattice QCD groups that treat major internal software as uncredited tools will systematically under-reward the people who build them.
  • Career paths tied mainly to paper counts will continue to discourage investment in sustainable, well-documented research software.
  • Disputes that mix authorship, software, supervision, and collaboration governance can fall between institutional mandates even when each body follows its own rules.
  • Community bodies could usefully develop shared norms for when long-term software and conceptual infrastructure warrant co-authorship versus citation or acknowledgement.
  • Open-sourcing code without matching recognition norms may still leave early-career builders professionally exposed inside the same institute or collaboration.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Similar credit gaps are likely in any HPC-heavy field where PhD and postdoc labor builds multi-year simulation stacks that outlive individual appointments.
  • Making software DOIs citable is necessary but not sufficient; without authorship or equivalent career currency, the incentive problem remains.
  • Transparent, two-sided access to evidence in integrity procedures would make later public case studies less one-sided and more usable for community learning.
  • Explicit contribution taxonomies agreed at project start could reduce later fights over whether infrastructure work counts as authorship.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The manuscript presents a first-person case study from lattice QCD on authorship and credit for long-term research software and related conceptual work. Using a documented sequence involving parallel arXiv submissions (Refs. 13–14), reuse of analysis and infrastructure codes, an OWID ombuds procedure, and subsequent collaboration decisions, it argues that traditional authorship norms and existing German research-integrity and collaboration-governance mechanisms do not adequately capture substantial software and conceptual contributions. Public elements include software DOIs, GitStats contribution summaries (Fig. 1), DFG guideline 14 on conceptual design, and quoted OWID procedural limits. The piece is framed as a factual practice reflection aimed at stimulating community discussion (e.g. via LDIC/ReSA) rather than as a physics result or a formal misconduct adjudication.

Significance. If accepted as a practice reflection, the paper is timely: lattice QCD depends on multi-year software stacks often built by early-career researchers, while career metrics remain publication-centric. Strengths include transparent Competing Interests disclosure; checkable public artifacts (arXiv records, software DOIs, Fig. 1 GitStats on named repos); explicit engagement with DFG guidelines, FAIR4RS, and the RSE/credit literature (e.g. under-crediting of code contributors); and a clear normative ask for community standards rather than a claim of proven misconduct. The structural point—that open reuse, legal ownership, and integrity procedures can leave software-heavy contributions under-recognised—does not require settling the confidential priority dispute and is of genuine interest beyond the single case.

major comments (3)
  1. [§2 Context; §3] §2 and §3: The central structural claim is supportable from public materials, but the manuscript still leans on contested, one-sided chronology (conception priority of the Ref. 15 follow-up; what OWID did or did not engage; relative developer status) as if those points were established facts. Please separate more sharply (i) independently checkable items (parallel uploads, software DOIs/GitStats, quoted DFG/OWID rules, published acknowledgements) from (ii) the author’s interpretation of confidential procedure and priority. The latter should be explicitly labelled as the author’s account of a disputed record, especially given the Competing Interests statement and the OWID finding of no wrongdoing as reported in the text.
  2. [§3; Refs. 13–14] §3 (DFG guideline 14 / conceptual design) and the comparison of Refs. 13 and 14: The argument that conceptual design confers authorship rights is load-bearing for the case illustration. As written, readers cannot verify the claimed match between the programme suggested in Ref. 13 and the work in Ref. 14 without a concise, neutral side-by-side (scope, observables, simulation strategy) that does not presuppose the author’s priority narrative. Add a short factual comparison table or paragraph limited to published content so the guideline-14 discussion rests on citable overlap rather than assertion.
  3. [Figure 1; §2] Fig. 1 and the software-credit claim: Commit/line counts are used to support “substantive technical contributions” and to criticise diluted developer attribution in Ref. 14. GitStats totals do not by themselves establish scientific indispensability or exclusivity of contribution to the specific analysis in Ref. 14, and the caption notes that main/master branches barely evolved after Ref. 15. Qualify what Fig. 1 does and does not show (sustained stewardship vs. novel code for the new study; multi-author history of CL2QCD etc.), and tie credit claims to the reused packages actually cited for that work rather than cumulative career commits alone.
minor comments (6)
  1. [Figure 1] Figure 1 is extremely dense (multiple stacked GitStats panels, tiny type). Consider a simplified summary table of commits/lines/active periods per codebase for the principal authors, with full GitStats moved to supplementary material or a repository.
  2. [§3; §4] §1–§4 occasionally shift from descriptive practice analysis into rhetorical questions that read as advocacy. Tonally aligning those passages with the Abstract’s “factual account and reflection” framing would improve suitability for a formal journal.
  3. [Footnotes 1 and 3] Footnote 1 and footnote 3 add important citation-propagation detail but interrupt the main line; consider folding the essential facts into the body and shortening the footnotes.
  4. [§1; §4] Minor language/typos: e.g. “wheresuchinfrastructuredoesnotyetexist”, “This situationraisesnontrivial”, “in medio stat virtusand”; normalise spacing and punctuation throughout.
  5. [Front matter] Keywords line is unpunctuated and hard to parse; use semicolon- or comma-separated terms consistently.
  6. [References [19–23]; Data Accessibility] Ensure all software citations (BaHaMAS, CL2QCD, Monte Carlo C++ analysis tools, Script utilities) consistently list version, DOI/URL, and access date where relevant, matching Data Accessibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No formal circularity: reflective case study with no derivation, prediction, or uniqueness chain that reduces to its inputs by construction.

full rationale

This paper is a first-person practice reflection and institutional critique, not a scientific derivation. It advances no equations, fitted parameters, uniqueness theorems, or first-principles predictions. Its normative claim—that long-term research-software and related conceptual work sit uneasily with traditional authorship and with existing German integrity/collaboration machinery, so community standards may help—is supported by external, independently citable material (DFG guideline 14, OWID procedural texts, FAIR4RS, ReSA, Brown et al. on code credit, RSE surveys) plus publicly checkable records (parallel arXiv uploads, software DOIs, GitStats on named repos). Self-citations to the author’s software and to Ref. 13 document the case; they do not close a logical loop in which a claimed result is equivalent to its premise by definition. First-person stake and one-sided confidential evidence raise fairness/completeness questions, not circularity in the sense of this pass. No step matches self-definitional, fitted-input-as-prediction, load-bearing uniqueness import, ansatz-via-citation, or renaming-as-unification. Score 0; steps empty.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The argument rests less on free parameters than on contested factual premises and normative domain assumptions: that the author’s event narrative is reliable, that VCS contribution metrics indicate authorship-worthy intellectual contribution, that DFG/OWID rules should govern collaborative software credit this way, and that acknowledgments/DOIs are insufficient rewards. No new physical entities are introduced.

assumptions (5)
  • ad hoc to paper The author’s chronology of conception, software reuse, collaboration decisions, OWID handling, and CRC-TR211 exclusion is factually accurate in the aspects that support the structural critique.
    Load-bearing throughout §2–3; Competing Interests admits direct involvement; counterparty materials are unavailable by design.
  • domain assumption Substantial long-term research-software development (design, maintenance, usability) can constitute an intellectual contribution warranting scientific authorship under norms such as DFG Guideline 14, not merely tool provision.
    Stated in §1 and §4; required to move from ‘code was used’ to ‘exclusion from authorship is a credit failure’.
  • domain assumption Version-control statistics (commits, lines added, active years) are informative evidence of relative software contribution for credit discussions.
    Figure 1 and caption (18 Dec 2025 GitStats); used to challenge diluted developer acknowledgments in Ref. 14.
  • domain assumption Legal employer ownership of employee-written software and formal lawfulness of reuse do not settle academic recognition/authorship questions.
    §1 ownership discussion; separates IP law from research ethics.
  • domain assumption OWID procedural features as quoted (no reciprocal evidence access, no appeal, confidentiality limits on later use) correctly describe the applicable process and constrain fair assessment of complex software-authorship disputes.
    §3 citations to OWID guidelines [29] and critique of principles III.1(d),(f).

how reviews work

0 comments
Cite this review

Pith. "Pith review of On credit attribution and research software: A case study from lattice QCD." pith.science (2026). https://pith.science/paper/JDM73ZWW

@misc{pith2026260728444,
  author       = {Pith},
  title        = {Pith review of: On credit attribution and research software: A case study from lattice QCD},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JDM73ZWW}},
  note         = {Machine review of arXiv:2607.28444}
}
read the original abstract

Questions of authorship, credit attribution, and the recognition of research software contributions have become increasingly prominent in those constantly growing research areas for which software constitutes an essential part of the research process. While general guidelines and best practices exist, their application in concrete situations often raises nontrivial interpretative and procedural issues. This article presents a documented case study from lattice QCD research, illustrating how the development of numerical strategies, long-term software infrastructure, and conceptual extensions of existing work can give rise to complex questions of authorship, priority, and credit attribution. Rather than discussing the underlying scientific results, the focus is on the sequence of events, the role of software as a long-term research infrastructure, and the interaction with established mechanisms for credit attribution and research integrity assessment. The aim of this work is to contribute to transparency and discussion on how current practices and guidelines are applied in realistic collaborative environments, and to highlight structural tensions that may arise between open scientific collaboration, software sustainability, and traditional notions of authorship. The article is intended as a factual account and reflection on research practice, and aims to stimulate discussion on whether additional community standards for recognising long-term research software contributions may be beneficial within lattice QCD.

Figures

Figures reproduced from arXiv: 2607.28444 by the authors.

Figure 1
Figure 1. Overview of contributions to codebases [19, 21–23] used in Ref. 14 done with GitStats [24] on 18 December 2025 from the repository main branch. PLASMA has not yet been publicly released and therefore other contributors are kept anonymous. After the work presented in Ref. 15 in 2021, all main or master branches of all codebase have substantially not evolved. Page 5 of 11 [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references

  1. [1]

    Markus Konkol,Daniel NüstandLaura Goulier:«Hail, software!»In:Nature Computational Science. Vol. 1 (pp. 89–89).2021. Available viadoi

    2021

  2. [2]

    In:PeerJ Comput

    David Schindleret al:«The role of software in science: a knowledge graph-based analysis of software mentions in PubMed Central». In:PeerJ Comput. Sci.Vol. 8 (e835).2022

    2022

  3. [3]

    Eva Maxfield Brown,Isaac SlaughterandNicholas Weber:Code Contribution and Credit in Science

  4. [5]

    Available viaarXiv

    Ivan Girottoet al:Advanced Techniques for Scientific Programming and Collaborative Development of Open Source Software Packages at the International Centre for Theoretical Physics (ICTP).2013. Available viaarXiv

    2013

  5. [6]

    In:Nature Computational Science

    Alexandre Hocquetet al:«Software in science is ubiquitous yet overlooked». In:Nature Computational Science. Vol. 4 (pp. 465–468).2024. Available viadoi

    2024

  6. [7]

    In:Frontiers in Physics

    Estela Suarezet al:«Energy efficiency trends in HPC: what high-energy and astrophysicists need to know». In:Frontiers in Physics. Vol. 132025. Available viadoi

  7. [8]

    Forschungszentrum Jülich:«The Research Software Engineering Initiative: Past, Present and Future»

  8. [9]

    Versionv0.9.3

    Simon Hettricket al:«International RSE Survey 2022». Versionv0.9.3. 2022.doi: 10.5281/zenodo. 7015772orhere(visited on 30 July 2026)

    doi:10.5281/zenodo 2022

Show all 31 references
  1. [10]

    Available here (visited on 30 July 2026)

    Dr Michelle Barkerandother:«Research Software Alliance». Available here (visited on 30 July 2026)

    2026

  2. [11]

    Katz:«Software Citations and the ACAT Community»

    Daniel S. Katz:«Software Citations and the ACAT Community». In:Journal of Physics: Conference Series. Vol. 1085 (p. 022010).2018. Available viadoi

    2018

  3. [12]

    Stokesandother:«About the Lattice Diversity and Inclusion Committee»

    Finn M. Stokesandother:«About the Lattice Diversity and Inclusion Committee». Availablehere (visited on 30 July 2026). [13]Alessandro Sciarra:«The chiral phase transition in the 3D Columbia plot».2025. Available viaarXiv. Page 10 of 11 On credit attribution and research softwa...

    2026

  4. [14]

    In:The European Physical Journal C

    Alfredo D’Ambrosioet al:«On the nature of the QCD chiral phase transition with imaginary chemical potential». In:The European Physical Journal C. Vol. 862026. Available viadoiorhere

  5. [15]

    In:Journal of High Energy Physics

    Francesca Cuteri,Owe PhilipsenandAlessandro Sciarra:«On the order of the QCD chiral phase transition for different numbers of quark flavours». In:Journal of High Energy Physics. Vol. 20212021. Available viadoior viaarXiv

  6. [16]

    In:Proceedings of The 39th International Symposium on Lattice Field Theory — PoS(LATTICE2022)

    Alfredo D’Ambrosio,Owe PhilipsenandReinhold Kaiser:«The chiral phase transition at non-zero imaginary baryon chemical potential for different numbers of quark flavours». In:Proceedings of The 39th International Symposium on Lattice Field Theory — PoS(LATTICE2022). Vol. 430 (p....

    2023

  7. [17]

    2017–2029

    Universities of Bielefeld, Frankfurt and Darmstadt:«Collaborative Research Center TransRegio 211». 2017–2029. Availablehere(visited on 30 July 2026)

    2017

  8. [18]

    An Online catalogue

    Alessandro SciarraandFrancesca Cuteri:Columbia plots and alike. An Online catalogue. Versionv1.0

  9. [19]

    Versionv0.3

    Alessandro Sciarraet al:Monte Carlo C++ analysis tools. Versionv0.3. 2024. Available viadoior here

    2024

  10. [20]

    In:Proceedings of The 41st International Symposium on Lattice Field Theory — PoS(LATTICE2024)

    Jan Philipp Klinger,Reinhold KaiserandOwe Philipsen:«The order of the chiral phase transition in massless many-flavour lattice QCD». In:Proceedings of The 41st International Symposium on Lattice Field Theory — PoS(LATTICE2024). Vol. 466 (p. 172).2025. Available viadoi. [21]Ale...

    2025

  11. [25]

    Available viaarXiv

    Mohammad Al-Turanyet al:JENA Computing Initiative WP2 Report: Software and Heterogeneous Architectures.2025. Available viaarXiv

    2025

  12. [26]

    In:Scientific Data

    Michelle Barkeret al:«Introducing the FAIR Principles for research software». In:Scientific Data. Vol. 9 (p. 622).2022. Available viadoi

    2022

  13. [27]

    Code of Conduct.2022

    Deutsche Forschungsgemeinschaft:Guidelines for Safeguarding Good Research Practice. Code of Conduct.2022. Available viadoi

    2022

  14. [28]

    Availablehere

    Deutsche Forschungsgemeinschaft:Rules of Procedure for Dealing with Scientific Misconduct.2024. Availablehere

    2024

  15. [29]

    Availablehere

    OWID e.v.:Procedural Guidelines of the Ombuds Committee for Research Integrity in Germany.2025. Availablehere

    2025

  16. [30]

    Availablehere(visited on 30 July 2026)

    Deutsche Forschungsgemeinschaft:«FAQs for complainants/whistleblowers who wish to report an incident to the DFG’s Compliance Ombudsperson». Availablehere(visited on 30 July 2026). [31]M. Jouvinet al:«Software Licence Agreements HSF Policy Guidelines».2016. Available viadoi

    2026

  17. [32]

    François Fluckiger:Final Report of the Open Source Software Licence Task Force. Tech. rep. Geneva: CERN,2012. Availablehere. [33]GSI/FAIR:«Open source software licences at GSI/FAIR -Guidelines».2021. Availablehere

    2012

  18. [34]

    Available viaarXiv

    Tomislav Maricet al:A Research Software Engineering Workflow for Computational Science and Engineering.2022. Available viaarXiv

    2022

  19. [35]

    Carlos Martinez-Ortizetal:PracticalguidetoSoftwareManagementPlans.Version 1.1.2023.Available viadoi

    2023

  20. [36]

    In:F1000Research

    H Anztet al:«An environment for sustainable research software in Germany and beyond: current state, open challenges, and call for action [version 2; peer review: 2 approved]». In:F1000Research. Vol. 92021. Available viadoi

  21. [37]

    Allenet al:Ten simple rules for PIs to integrate Research Software Engineering into their research group.2025

    Stuart M. Allenet al:Ten simple rules for PIs to integrate Research Software Engineering into their research group.2025. Available viaarXiv. Page 11 of 11

    2025

  22. [2021]

    Availablehere(visited on 30 July 2026)

    2026

  23. [2026]

    [4]Arfon M

    Available viaarXiv. [4]Arfon M. Smithet al:Astro2020 APC White Paper: Elevating the Role of Software as a Product of the Research Enterprise.2019. Available viaarXiv

    2019

Pith tools

Reviewed July 31, 2026 · model on record in the stance chip above.