sigmod-reproducibility
GitHub辅助SIGMOD投稿强化可复现性，涵盖代码数据共享、实验溯源（版本/配置/数据集/硬件）、系统指标分布报告及基线公平性披露。通过追踪可复现债务确保论文结果可信并符合PACMMOD规范。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sigmod-reproducibility -g -y
SKILL.md
Frontmatter
{
"name": "sigmod-reproducibility",
"description": "Use when hardening the reproducibility story of a SIGMOD submission, covering PACMMOD's expectation that code, data, scripts, and notebooks be shared, experiment provenance from config to figure, dataset and workload disclosure, variance reporting for systems numbers, and alignment with later ARI badging."
}
SIGMOD Reproducibility
PACMMOD's author guidelines state the culture plainly: sharing research
artifacts should be the norm, and papers are expected to make code, data,
scripts, and notebooks available where possible — encouraged rather than
mandatory for acceptance, but reviewers read availability as a credibility
signal. This skill covers reproducibility as engineered into the paper;
the post-acceptance badge process lives in sigmod-artifact-evaluation.
Provenance chain, not vibes
A database paper's result is a function of code version, configuration, dataset, workload, and hardware. Reproducibility means the paper pins all five for every number it prints.
| Layer | Must be recoverable from paper + artifact | Where it usually hides |
|---|---|---|
| Code version | Commit or tag behind each experiment | "latest" at submission time |
| Configuration | Buffer sizes, thread counts, compaction/GC settings, flags | Defaults nobody recorded |
| Dataset | Source, version, generator seed, scale factor | "standard benchmark data" |
| Workload | Query mix, arrival pattern, skew parameters, warm/cold state | The harness script |
| Hardware | CPU model, cores, RAM, storage class, network, OS/kernel | A single sentence, if any |
The practical test: could a competent stranger fill this whole table from your materials? Every empty cell is a review question waiting to be asked in the feedback phase.
Systems numbers need distributions
Throughput and latency are noisy. The SIGMOD-credible floor:
- Repeated runs with the repetition count stated; medians or means with a spread measure, never a single lucky run.
- Latency reported at named percentiles (p50/p95/p99), since tail behavior is often the actual contribution.
- Warm-up policy stated: what was cached, JIT-compiled, or pre-compacted before measurement started.
- Cross-run controls named: same machine, isolated tenancy, pinned cores, disabled turbo — whatever was actually done, said explicitly.
Fairness to baselines is reproducibility too
The most contested numbers in a data-systems paper are the competitor's. Record and disclose: which version of each baseline, who tuned it and how, which of its features were enabled, and whether its authors' recommended configuration was used. An artifact that reproduces your system but ships an untuned strawman baseline reproduces the wrong thing.
Repro debt ledger
Track gaps while writing rather than reconstructing at deadline:
# repro-ledger.md (kept in the paper repo)
| Paper item | Script | Data pinned | Config pinned | Runs/variance | Status |
|-----------|--------|-------------|---------------|---------------|--------|
| Fig 6 | exp/f6.sh | yes (sf=100, seed 41) | yes | 5 runs, p50/p99 | OK |
| Fig 7 | exp/f7.sh | yes | NO — flags undocumented | 1 run | DEBT |
| Tab 2 | manual | partial | yes | n/a | DEBT: script it |
Rule: nothing with status DEBT appears in the submitted PDF. The ledger later becomes the ARI claims map almost verbatim.
Pinning, mechanically
The cheapest insurance is captured at run time, not reconstructed later:
# stamped into every experiment's log directory by the harness
git -C "$ENGINE_DIR" rev-parse HEAD > meta/engine.commit
"$ENGINE" --dump-effective-config > meta/config.effective
sha256sum data/*.bin > meta/datasets.sha256
lscpu; free -h; uname -r; nvme list >> meta/hardware.txt
echo "$WORKLOAD_SEED $QUERY_MIX $SKEW" > meta/workload.params
Five commands, and the provenance table fills itself for every figure. The
--dump-effective-config line matters most: defaults you never set are
still part of the experiment, and engines change defaults between versions.
Data you cannot publish
Industrial collaborations often involve proprietary workloads. The accepted pattern at SIGMOD: characterize the private data (sizes, distributions, skew, schema shape), provide a public or synthetic stand-in that exhibits the same phenomena, run headline experiments on both, and say which conclusions are supported by the public path alone. A paper whose every claim requires private data cannot be badged and will be read skeptically.
Multi-round consistency
Because SIGMOD reviewing spans rounds, reproducibility discipline has a second job: your own revision. Reviewers may demand new experiments with a one-month window — regenerating the whole evaluation under a new flag is only survivable if the original runs were scripted, seeded, and logged. Teams that hand-ran their plots discover this during the revision, at the worst time.
What reviewers can check without running anything
Even reviewers who never open the artifact test reproducibility passively: do the numbers in the abstract, the results section, and the conclusion agree; do figure axes and caption units match the prose; does the claimed hardware plausibly fit the claimed dataset in memory; do percentages in tables sum sensibly. Internal inconsistency is read as evidence that the pipeline is hand-operated — and it usually is. A final numeric-consistency pass over the PDF is reproducibility work, not copyediting.
Output format
[Sharing posture] full artifact / partial / withheld with stated reason
[Provenance table] complete cells vs. gaps, per figure and table
[Variance floor] repetitions, spread measures, percentile reporting
[Baseline fairness] versions, tuning provenance, config disclosure
[Private-data plan] public stand-in coverage of headline claims
[Debt ledger] items that must close before the round deadline
Version History
- 9f86f09 Current 2026-07-19 17:37
