Operations Research revisions are technical. Reviewers expect the mathematics and computation to actually change, not just the prose. Structure the response so every point is traceable:
| Reviewer ask | Substantive response |
|---|---|
| "Proof gap / assumption smuggled in" | Repair the proof; state where each assumption is used; add a lemma if needed |
| "Assumption too strong" | Weaken it (relaxation/counterexample) or justify necessity with a counterexample |
| "Bound not tight" | Prove tightness with a matching instance, or reframe as best-known |
| "Missing baseline / weak instances" | Add the closest prior method and recognized benchmark instances; rerun |
| "Stochastic results unreliable" | Add confidence intervals, more replications, CRN, fixed seeds |
| "Not reproducible" | Provide the ORJournal repo: README/LICENSE, structure, runnable scripts |
If accepted in principle, code/data go through the ORJournal GitHub pull-request process: a structured repository with README/LICENSE, the prescribed directory structure, and documented hardware/software/data/installation/run steps so a reviewer can regenerate the results. Pin versions and seeds. If data are confidential/licensed/non-public or the paper is purely methodological, ensure the exemption (requested in the cover letter, decided by the Area Editor with EiC authority) is in place. Respond promptly to reproducibility comments on the PR.
【Response letter】point-by-point, verbatim quotes + change locations?
【Editor synthesis】binding points addressed first?
【Technical fixes】proofs / assumptions / bounds / baselines / stochastic care
【Reproducibility】ORJournal repo ready / exemption in place?
【Format】equation-free intro; within page tier; e-companion ≤ manuscript
【Next step】resubmit → ors-review-process (next round) or ors-submission (final checks)