JOSS six-month public development and validation roadmap

[D-sudoasd]

Objective

Build the public development, validation, research-use, and archival evidence needed for a defensible JOSS submission after the six-month public-development threshold.

Public baseline date: 2026-08-12
Earliest six-calendar-month date: 2027-02-12
Planned final readiness review: 2027-02-15

Software and reproducibility

• Keep CI green on Python 3.10–3.13, Windows, macOS, Linux, and the headless GUI smoke test.
• Review and merge dependency updates only after the full matrix passes.
• Run the monthly reproducibility audit and investigate every discrepancy.
• Record user-facing bug fixes, scientific-contract changes, and validation improvements in CHANGELOG.md.
• Maintain deterministic analytic-benchmark and offline-demo evidence bundles.

Independent scientific validation

• Compare indexed peak positions and systematic absences against at least one independent crystallographic implementation.
• Compare multiplicities and structure-factor channels for representative cubic, hexagonal, tetragonal, orthorhombic, monoclinic, and triclinic structures.
• Validate hkl-normal Young's modulus against an independent tensor implementation for multiple crystal symmetries.
• Document tolerances, software versions, input structures, coordinate-frame assumptions, and discrepancies.
• Add each accepted validation case to validation_cases/ with a manifest and reusable command.

Real research use

• Publish at least one complete real-material workflow from chemical-system query to an auditable diffraction-reference bundle.
• Record how the output informed experimental planning, phase screening, or interpretation without claiming automatic phase identification.
• Obtain at least one independent installation and use report from a researcher outside the original development workflow.
• Resolve or document all user-reported installation, data-contract, and scientific-interpretation issues.

Documentation and community

• Keep README, GUI guide, API guide, scientific contracts, and examples synchronized with released behavior.
• Record external issues, pull requests, discussions, or validation feedback as public evidence.
• Review accessibility and first-install experience on a clean Windows research workstation.
• Confirm author metadata, ORCID, affiliation, acknowledgements, funding, and AI-use disclosure.

Release and submission package

• Freeze scientific definitions and output schemas for the submission release.
• Create the final tagged GitHub Release and verify every uploaded SHA-256 value.
• Archive the tagged release in Zenodo or another long-term repository and obtain a DOI.
• Update CITATION.cff, paper/paper.md, and release metadata with the archive DOI and final version.
• Build the manuscript with the Open Journals workflow and inspect the rendered PDF.
• Run python scripts/joss_readiness.py --output build/joss-readiness and resolve every blocking item.
• Submit only after the public timeline, real-use evidence, independent validation, community evidence, archive DOI, and manuscript audit are complete.

Evidence rule

Scheduled automation alone does not count as substantive development. Each checked item must link to a public commit, issue, pull request, release, validation bundle, research-use record, or archive record that supports the claim.