sigmod-writing-style
GitHub指导SIGMOD系统论文写作，涵盖首段核心契约、贯穿案例、精准量化主张、架构优先叙事及匿名化表达，助作者利用12页篇幅清晰呈现工程论证与评估结果。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sigmod-writing-style -g -y
SKILL.md
Frontmatter
{
"name": "sigmod-writing-style",
"description": "Use when revising a SIGMOD research paper's prose and structure, covering the data-management framing readers expect on page one, running examples and architecture figures, scoping systems claims to measured workloads, third-person anonymity phrasing, and fitting a systems argument into 12 ACM-template pages."
}
SIGMOD Writing Style
SIGMOD prose is engineering argumentation: a reader who builds database systems should finish page one knowing what breaks today, what mechanism you built, and what measurement proves it. The 12-page ACM-template budget (references excluded) is generous by conference standards, which removes the usual excuse — at this venue, missing detail reads as concealment rather than compression.
Page-one contract
Within the first page, in some order: the workload or application pressure that makes the problem real now; why the incumbent technique fails at that pressure point (with a number if possible); the mechanism in one concrete sentence; the headline measured result with its setting attached; and the contribution list phrased as artifacts a reader can verify — an algorithm, a system component, a proof, an evaluation.
A first paragraph that opens with "Data volumes are growing exponentially" has already spent its welcome; open instead inside the specific bottleneck.
The running example
The single most recognizable SIGMOD stylistic device: one small, concrete example — a table, a query, a workload snippet — introduced in Section 1 or 2 and threaded through the design sections. Every operator, data structure, or protocol step is shown acting on it. Papers that explain a join algorithm purely in symbols, when three rows and two tables would show it, get "hard to follow" reviews from people fully capable of reading the symbols.
Claim scoping for systems numbers
| Draft claim | Survives review as |
|---|---|
| "Up to 10x faster than X" | "10x on skewed reads at sf=100; 1.3x on uniform writes (Fig 8)" |
| "Scales linearly" | "Near-linear to 64 cores; contention flattens beyond (Fig 9)" |
| "Negligible overhead" | "3-6% p99 latency overhead across the mixes tested (Tab 4)" |
| "Guarantees consistency" | "Snapshot isolation; serializable with Sec 4.3's lock, at cost Y" |
| "First system to..." | Scoped precisely, or cut — a PC full of builders will find prior art |
The pattern: attach every superlative to a figure, a workload, and a boundary. Database reviewers respect a stated limitation and hunt an unstated one.
Architecture before algebra
- One system-overview figure early, with components named identically in figure, prose, and evaluation — nomenclature drift across 12 pages is a real and common defect.
- Pseudocode for the core mechanism only; secondary routines are prose plus a pointer to the artifact.
- Correctness arguments get a proof sketch in the body and full detail in
the extended report (
sigmod-supplementary), but the invariant itself must be stated in the body, precisely. - Design-decision paragraphs ("we chose B over A because...") are not filler here; they are what industrial readers cite the paper for.
Anonymity-safe voice
Write about your own prior systems in the third person, and scrub the tells: "we extend the engine of [12]" not "we extend our engine [12]"; no internal codenames that a search engine maps to a company; no "deployed at a major cloud provider" phrasing that narrows the author set to two teams. These rules bind for the entire multi-round review, including revised text.
Budgeting the 12 pages
p1 Problem, failure of incumbents, mechanism, headline number
p2-3 Background + running example; the example does the teaching
p4-7 Design: architecture figure, core algorithm, invariants
p8 Correctness/complexity sketch; report carries the full proof
p9-11 Evaluation: setup table first, then claims in figure order
p12 Related work in contrast form + limitations + conclusion
Treat the evaluation-setup half page as immovable: hardware, datasets, workloads, baselines, tuning provenance. Cutting it to rescue a design subsection trades a clarity comment for an evidence objection — a bad trade in this reviewer pool.
Title and abstract mechanics
- System papers at this venue conventionally lead with the system name and
a colon-scoped promise ("X:
for "); earn the name by making the mechanism clause precise, not grand. - The abstract must contain at least one number with its setting attached; an abstract with zero measurements signals a position paper.
- Avoid "novel," "framework," and "holistic" — three words this reviewer pool has learned to read as absence of specifics.
- The abstract's last sentence should say what is released: code, data, scripts. PACMMOD's sharing expectation makes silence conspicuous.
Sentence-level habits
- Present tense for the system's behavior, past tense for what experiments did.
- Numbers over intensifiers: "2.1x" not "significantly"; "p99" not "tail".
- Name the enemy precisely: "log-structured merge amplification" beats "performance issues of existing approaches".
Output format
[Page-one audit] pressure / incumbent failure / mechanism / number present?
[Running example] exists and threads through design sections yes/no
[Claim ledger] each superlative -> figure + workload + boundary
[Voice sweep] third-person self-references, codename leaks
[Budget check] section allocation vs. the 12-page plan
[Priority rewrites] ordered list
Version History
- 9f86f09 Current 2026-07-19 17:37
