How JHCS peer-reviews computer-science manuscripts — the rubric we grade against, the reviewer credentials we require, the plagiarism and code-similarity tools we run, our retraction rules, and the publication licenses we apply to text and code.
JHCS publishes rigorous, evidence-based computer-science research authored by high-school students. We hold student authors to the same standards a peer-reviewed CS conference would apply: novel technical contribution, empirical rigor, and a runnable artifact that anyone can reproduce. Manuscripts outside computer science or its adjacent computational sciences are outside scope and will be desk-rejected. Tutorials, opinion pieces, un-evaluated proposals, and re-implementations without new insight are outside scope.
Authors choose single-blind or double-blind at submission. Double-blind is the default. Under double-blind, author-identifying information must be removed from the manuscript, from figures, from acknowledgments, and from the artifact repository at submission. Editors handling a submission recuse themselves in the event of any conflict of interest — former teacher, family, coauthor within the last five years, or shared institution during the research period.
Reviewers score each manuscript on five CS-specific dimensions on a 1–5 scale:
| Dimension | What we look for |
|---|---|
| Novelty of contribution | A real algorithmic, theoretical, or systems contribution — a new algorithm with a stated complexity result; a proof of a bound or property; a system with a design a competent engineer could not have written unaided; a model or dataset that changes what we can measure. Reviewers ask: what does this paper let us do that we couldn't before? |
| Empirical rigor | Strong baselines (at least one published baseline), ablations that isolate each design choice, statistical validity (multiple seeds, error bars, significance tests, honest handling of variance), and reported hyperparameters, hardware, and wall-clock cost. |
| Reproducibility | Does the code actually run? Reviewers clone the artifact repo, follow the README, and reproduce at least one headline result. A paper whose artifact does not install or does not produce the reported numbers cannot pass this criterion. |
| Software-engineering quality | Is the code readable, documented, and tested? Is the repository organized (clear src/, tests/, data/)? Are dependencies pinned? Is there a smoke test or CI? Reviewers do not require production-grade engineering, but a random unlabelled Jupyter notebook is not sufficient. |
| Clarity of writing | Is the paper well-structured, precise, and honest about limitations? Are figures readable? Is pseudocode correct? Is the AI-use disclosure complete? |
JHCS reviewers are PhD students or postdoctoral researchers in a relevant computer-science subfield, or industry researchers with peer-reviewed CS publications. We prefer at least one reviewer per manuscript whose primary research area matches the paper's track (e.g. an ML reviewer for an ML paper, a systems reviewer for a systems paper). Reviewers are recruited through the editorial board and vetted for expertise and conflicts before assignment.
Round 1 asks a single question: can this paper become publishable? Reviewers weigh novelty, method, and whether the artifact runs above all else. Roughly 30% of submissions advance. Papers that lack a meaningful CS contribution or whose method/artifact cannot support their claims are declined here, with a written explanation.
Round 2 asks whether concerns raised in Round 1 have been addressed — new baselines added, ablations run, statistical tests corrected, code cleaned up. Reviewers verify the artifact still installs after changes.
Round 3 covers polish, license selection, and a final reproducibility spot-check.
Every JHCS submission includes a public GitHub artifact (see submission guidelines §5). Reviewers are asked to clone the repo and reproduce at least one headline result. On acceptance, authors publish the permanent, de-anonymized artifact link (GitHub with a Zenodo DOI mint is preferred) and select a code license (see §10).
Where code cannot be released (for example because of a partner organization's policy or a responsible-disclosure embargo), authors must justify this to the editors and provide the code confidentially for review only. Confidential-only artifacts cap the paper's reproducibility score.
JHCS runs the following automated checks on every submission that passes desk check:
These tools inform — they do not decide. Editors weigh their output alongside the disclosure and the manuscript before acting.
JHCS retracts a published paper when any of the following are established post-publication:
Retractions are issued as a signed editorial notice from the Editor-in-Chief, linked from the original paper's landing page, and marked on the archive listing. In serious cases the editors may notify the authors' school. Correction (rather than retraction) is used where the error is honest and the paper's core claim survives with a fix.
LICENSE file at the repository root.Authors who believe a decision was made on factually incorrect grounds may write to the Editor-in-Chief within 30 days. Appeals do not re-open the substantive judgment of reviewers, but the Editor-in-Chief will confirm whether the process was applied correctly and, in rare cases, order a fresh review.