Submission Guidelines

1.Who can submit

JHCS publishes work authored by students currently enrolled in grades 9–12 (or the international equivalent) at the time of submission. Papers may be single-authored or co-authored by a team of students. A mentor, teacher, advisor, or research supervisor may be acknowledged, but the intellectual work, the code, and the writing must be the students' own. Adult mentors must not appear as authors.

2.Scope & CS fields

JHCS publishes evidence-based computer science research across the full range of CS subfields:

• Machine Learning & AI — deep learning, RL, NLP, computer vision, ML systems, model evaluation, safety.
• Algorithms & Theoretical CS — algorithm design, complexity theory, formal methods, cryptography.
• Systems & Networking — operating systems, distributed systems, databases, storage, networking, embedded/IoT.
• Programming Languages & Software Engineering — compilers, language design, static analysis, testing, empirical SE.
• Security & Privacy — applied cryptography, systems and network security, usable security, privacy engineering.
• Human-Computer Interaction — interaction techniques, accessibility, education technology, empirical HCI.
• Computational Sciences — computational biology, computational social science, robotics, quantum computing, computer graphics.

Interdisciplinary work is welcome provided the computer-science contribution is primary and is evaluated.

3.Accepted paper types

4.Manuscript format

Template

Submit a PDF generated from one of the following templates:

• LaTeX — ACM sigconf (acmart), or
• LaTeX — IEEE conference (IEEEtran conference mode), or
• Markdown compiled to a 2-column PDF via Pandoc + a supported template (Eisvogel or a JHCS starter we provide on request).

We do not accept Word (.docx). LaTeX/Markdown produces reproducible typesetting and works cleanly with reviewer diffing and revision control.

Required sections (in this order)

1. Abstract. 150–250 words. Problem, method, results, artifact URL (blind).
2. Introduction. Motivation, contributions listed as a bulleted “contributions” paragraph, roadmap.
3. Related Work. Situates the paper against prior CS literature. Not a survey.
4. Methods / Algorithm / Model / System description. Precise enough to reimplement. Include pseudocode or a system diagram.
5. Experiments. Datasets, baselines, hyperparameters, training/eval protocol, hardware.
6. Results. Tables and figures with error bars, ablations, and statistical significance tests where applicable.
7. Discussion. Interpretation, limitations honestly stated, threats to validity, future work.
8. Ethics. Data provenance, participant consent, dual-use considerations, responsible disclosure (for security work).
9. Reproducibility. Link to the artifact repository, environment spec, expected runtime, hardware, and what a reviewer needs to reproduce the headline result.
10. AI Use. A short section disclosing any use of LLMs or code assistants (see §7).
11. References. ACM or IEEE reference style; every URL/DOI resolvable.

Length & style

Full papers are 8–15 pages in ACM/IEEE 2-column format, excluding references. Short papers are 4–6 pages. Figures and tables must be numbered and captioned. Code snippets typeset in a monospace font (e.g. JetBrains Mono) with clear line breaks; listings longer than half a column belong in the artifact repo and should be referenced from the paper.

5.The artifact requirement (GitHub repo)

Every submission must include a public GitHub repository link (anonymized for review). The repository is peer-reviewed alongside the manuscript. A minimum-viable artifact contains:

1. Reproducible code for the main experiments — not just a demo, but the exact scripts that produced the paper's headline numbers.
2. Dataset citation(s) or the dataset itself with a clear license. Public datasets: cite with version and access instructions. Author-collected datasets: release them with a license, or provide a small released subset plus a data statement.
3. A README with a ≤10-command quickstart that produces the headline result on a fresh machine.
4. A machine-readable environment spec: one of requirements.txt, environment.yml, package.json (with lockfile), Cargo.toml, or a Dockerfile.

Optional but strongly preferred:

• A published Docker image tagged to the submission commit.
• Jupyter/Marimo notebooks that regenerate every figure in the paper, checked in with executed outputs.
• A CI badge proving the artifact builds and tests pass on a public runner.
• An ACM Artifact Review-style REQUIREMENTS.md listing exact CPU/GPU/RAM/disk expectations.

Expected repository skeleton:

$ tree -L 2 my-jhcs-submission/
my-jhcs-submission/
├── paper/
│   ├── main.tex             # ACM sigconf or IEEE conference; anonymized
│   ├── refs.bib
│   └── figures/
├── src/
│   ├── model.py
│   ├── train.py
│   ├── evaluate.py
│   └── utils/
├── data/
│   ├── README.md            # dataset citation, license, access notes
│   └── splits/              # fixed train/val/test splits with hashes
├── notebooks/
│   ├── 01_dataset_stats.ipynb
│   └── 02_regenerate_figures.ipynb   # exec outputs checked in
├── tests/
│   └── test_smoke.py
├── reproduce.py             # one-command headline result
├── requirements.txt         # pinned; or environment.yml / Dockerfile
├── Dockerfile               # optional but preferred
├── REQUIREMENTS.md          # CPU/GPU/RAM/disk expectations
├── README.md                # quickstart in ≤10 commands
└── LICENSE                  # MIT / Apache-2.0 / BSD-3-Clause

Reviewers are asked to actually clone the repo and reproduce at least one headline result. A repository that does not install, does not run, or omits the code behind the paper's numbers is grounds for rejection independent of the manuscript.

6.Experiments, statistics & reporting

Empirical claims must be supported by evidence a competent CS reader would trust:

• Baselines. Compare against at least one strong published baseline (not just a trivial random or majority-class baseline).
• Multiple runs. Report mean and standard deviation across ≥3 seeds. Single-run ML numbers are considered incomplete.
• Error bars on every reported metric. Bar charts and headline tables must show variance (std, IQR, or bootstrap CI).
• Statistical significance tests where a claim depends on a numerical difference — paired t-test, Wilcoxon, McNemar, bootstrap CI, whichever is appropriate. Report the test, the statistic, and the p-value.
• Ablations. Isolate each design choice you claim matters.
• Seeds & hardware. Report seeds for RNGs. Report CPU/GPU, RAM, and wall-clock training/eval time.
• Failure modes. Where your method underperforms — report it. Reviewers weight honesty highly.

7.AI-use disclosure

You may use AI assistants (Claude, GPT, Gemini, GitHub Copilot, Cursor, etc.) as tools, in the same way you might use a linter, a debugger, or Stack Overflow. You may not present AI-generated text as your own analysis, or AI-produced results as your own experiments.

Every submission must include an “AI Use” section before the references, disclosing:

• Which tools were used (model name and version if known).
• What each was used for — e.g. “Claude Sonnet 4.5 for paragraph-level editing of the Introduction; GitHub Copilot for boilerplate PyTorch training-loop scaffolding; ChatGPT for brainstorming baseline candidates.”
• What you verified yourself — e.g. “all cited references were independently checked; all code was reviewed line-by-line and tested.”

Failure to disclose is treated as research misconduct. AI cannot be listed as an author.

8.Ethics, IRB & integrity

Every JHCS submission must be original work, honestly reported. Fabrication, falsification, and plagiarism are grounds for immediate desk rejection and, in serious cases, for notifying the author's school.

• Human-subjects research. User studies, HCI experiments, surveys of humans, and any work involving personal data must go through IRB or an equivalent institutional review where possible. Where the author's school has no IRB, describe the ethics protocol you followed (consent language, data retention, minor-participant safeguards) and provide it as supplementary material.
• Security research. Follow responsible-disclosure norms; if you found a vulnerability, describe the disclosure timeline in the paper.
• Scraped or sensitive data. Explain why the collection was permissible under the source's terms of service, and describe what you did to protect the individuals in the data.
• Dual use. If a technique has a plausible harmful application (e.g. surveillance, exploit development), address it honestly.

9.Preprints & blinding

• Preprints on arXiv are permitted and encouraged. If a preprint is up, mention it in the cover letter with the arXiv ID; it does not affect eligibility.
• Author's choice of blinding. Authors may request single-blind (author identity known to reviewers) or double-blind (identities hidden both ways) review at submission. Double-blind is the default and remains our recommendation.
• Anonymization is required under double-blind: remove author names and affiliations from the manuscript, artifact repository, and figures.

10.Review process & timeline

All submissions receive peer review against a rubric on novelty, empirical rigor, reproducibility, software-engineering quality, and clarity. First-round reviews are returned within 2 weeks for the fast track (a full report inside 14 days) or within the standard 4–6 weeks for extended review; revised submissions are re-reviewed in 2–4 weeks. A round fee of $100 applies to each of up to three rounds. See the editorial policy for the full rubric and decision language.

11.How to submit

1. Create an account in the submission portal.
2. Start a new submission and upload:
   • The anonymized PDF compiled from your ACM/IEEE LaTeX source.
   • A link to the anonymized GitHub repository containing your artifact.
   • The AI-use disclosure (already inside the PDF; also summarized in the portal form).
   • Any ethics documentation for user studies or sensitive-data work.
3. Pay the $100 round fee via PayPal from inside the portal.
4. You will receive a confirmation email with your Submission ID. Reviews and decisions are delivered inside the portal and by email.