Design the study to survive an empiricist's audit, because that is who reviews it. ICSE's rigor criterion scores "thoroughness and completeness of an evaluation" (2027 call wording, read 2026-07-08), and the community has strong default expectations per study type that function as unwritten checklists.
| Claim shape | Minimum evidence ICSE reviewers expect |
|---|---|
| "Technique X finds more bugs than Y" | Real subject programs, Y actually run (not quoted from its paper), same budget/timeout, statistics + effect size |
| "Developers struggle with Z" | Systematic observation: survey with stated sampling, interviews to saturation, or instrumented behavior — not anecdote |
| "LLM-based tool solves task T" | Ablations over prompts/models, contamination discussion, cost reporting, non-LLM baseline where one exists |
| "Metric M predicts defects" | Multiple projects, time-aware splits, comparison against trivial baselines (size, churn) |
| "Our benchmark/dataset enables research" | Construction protocol, quality validation sample, license clarity, comparison with existing sets |
The recurring failure is claim-evidence mismatch: a general claim ("improves program repair") evaluated on one narrow slice (single-hunk Java bugs from one dataset). Either widen the evidence or narrow the claim before reviewers do.
Rerun baselines in your environment with tuned-in-good-faith configurations and identical budgets. Where rerunning is impossible (unavailable code, proprietary systems), say so and downgrade the comparison's claims. A suspiciously weak baseline is the fastest way to lose a rigor score: reviewers know these tools' published numbers.
SE data are typically non-normal, so community convention favors non-parametric machinery: Mann-Whitney/Wilcoxon tests paired with an effect size — Vargha-Delaney Â12 or Cliff's delta — rather than bare p-values, with multiple-comparison correction when many hypotheses are tested. For stochastic techniques (search-based SE, LLM sampling), repeat runs (community folklore says ≥10, more is better), and report distributions, not single bests. These are norms, not posted rules — but a paper missing them collects the same review sentence every time.
Per comparison, report all four:
central tendency -> median across repetitions
dispersion -> IQR or min-max across seeds/runs
significance -> Mann-Whitney U (corrected if many tests)
effect size -> Â12 or Cliff's delta, with magnitude label
Plus: exact repetition count, budget/timeouts, hardware, and total compute.
For interviews, surveys, and coding studies the checklist changes shape: sampling strategy and saturation argument; codebook development story; a second coder with inter-rater agreement (Cohen's kappa or Krippendorff's alpha) on at least a sample; quotes traceable to anonymized participant IDs; instruments in the replication package. Mixed-methods papers are welcome at ICSE precisely when each half meets its own bar.
Write the threats-to-validity section before running the study, as a design
instrument: every internal-validity threat you can name pre-hoc (selection
bias, implementation bugs in your own tooling, evaluation-metric gaming) is
one you can still mitigate cheaply — a random audit sample, a sanity
experiment, an independent reimplementation of the metric. Threats discovered
during writing week can only be confessed, not fixed. This inversion is the
single highest-leverage habit in the ICSE evidence culture; see
icse-writing-style for how the section is then written.
Before believing any headline number, run the cheap falsifiers: a null-technique control (does a random or trivial variant score suspiciously close to your tool? then the metric, not the technique, is doing the work); a known-answer audit (hand-verify a random sample of your tool's outputs — SE evaluation pipelines mislabel more often than techniques fail); and a metric-implementation cross-check (compute one cell of the results table with an independent script). Papers retracted or majorly revised over evaluation bugs almost always lacked one of these three runs, each of which costs an afternoon.
When the technique wraps a model, reviewers want the wrapper separated from the model: fix the model and vary your components; fix your components and vary the model (at least one open-weights option so others can reproduce); report token/dollar/time costs; state decoding parameters and exact model versions with dates — "GPT-4" is not a reproducible identifier and will be flagged under verifiability.
[Claim inventory] each headline claim -> evidence row above -> met / gap
[Subjects] selection rule, scale, version pins, contamination status
[Baselines] rerun? tuned? budget-matched? which comparisons are downgraded
[Statistics] tests, effect sizes, repetitions, corrections present?
[Qualitative] sampling, codebook, agreement stats (if applicable)
[Pre-hoc threats] threats named at design time -> mitigation experiments queued