icse-experiments
GitHub指导ICSE研究论文的实验设计与审计，涵盖基准选择、基线公平性、统计检验及消融实验。强调证据与主张匹配，防范数据泄露，确保评估严谨性以符合SE社区评审标准。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill icse-experiments -g -y
SKILL.md
Frontmatter
{
"name": "icse-experiments",
"description": "Use when designing or auditing the evaluation of an ICSE research-track paper, covering subject and benchmark selection, baseline fairness, statistical tests and effect sizes as SE reviewers expect them, qualitative-methods rigor, ablations for AI-based techniques, and threats-driven study design."
}
ICSE Experiments
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.
Evidence proportional to claim
| 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.
Subjects and benchmarks
- Real programs, stated selection. Say how subjects were chosen — "all Defects4J v2 projects" beats "10 popular GitHub projects" because the latter invites cherry-picking suspicion. Report scale (kLOC, stars, age) so readers can judge representativeness.
- Version-pin everything. Repository SHAs, dataset versions, dependency locks; mining studies live or die on whether the corpus can be rebuilt.
- Guard against benchmark leakage in AI-for-SE work: if the model's training data plausibly contains your benchmark (most public code pre-2024 does), you must address contamination — held-out post-cutoff bugs, mutation of subjects, or explicit caveats. Reviewers now ask unprompted.
Baselines and fairness
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.
Statistics as the SE community practices them
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.
Qualitative rigor
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.
Threats-driven design
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.
Sanity experiments that catch your own bugs
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.
Ablations for AI-era SE papers
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.
Output format
[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
Version History
- 9f86f09 Current 2026-07-19 15:58
