EuroSys Writing Style
Use this on the manuscript itself. A EuroSys paper succeeds when a broad
systems PC — kernel people, distributed-systems people, cloud and security
people — can each extract the same mechanism and believe the same numbers
within one reading. The two-column acmart[sigplan] format and the 12-page
technical budget (EuroSys 2027 CFP, rendered 2026-07-08) reward density that
stays legible, not compression that hides.
The load order of a EuroSys introduction
- The operational pain, stated concretely enough to measure.
- Why the existing abstraction or mechanism structurally cannot fix it —
named systems, not "prior approaches".
- The insight: the one idea that unlocks the design.
- What was built, and the two or three numbers that prove the idea carries.
- Contributions as verifiable statements, each pointing at a section.
A reader who stops after page one should be able to state your insight in a
sentence. If the insight sentence does not exist, the problem is the research
framing, not the writing (route to eurosys-topic-selection).
Page budget that survives review
| Section |
Share of 12 pages |
Failure mode when misallocated |
| Intro + motivation |
~2 |
Motivation essay crowds out the design |
| Design + implementation |
~4.5 |
Mechanism described by metaphor, not by structure |
| Evaluation |
~4 |
Result dump with no questions being answered |
| Related work + discussion |
~1.5 |
Either a stub or a survey; both read badly |
References are free pages at EuroSys — cite generously and spend zero
technical pages on bibliography anxiety.
Design sections that reviewers can retell
- Name components and keep the names stable; a renamed component is a new
component to a tired reviewer.
- One architecture figure whose boxes match the subsection structure.
- For each mechanism: the invariant it maintains, the common-case path, the
failure path, and the cost you pay for it. The cost sentence is what
separates engineering description from research writing.
- Push code-level detail down to a listing only when the trick is the code.
Evaluation prose discipline
Open with the questions, then answer them in order:
§6 Evaluation. We answer four questions:
Q1 Does <system> improve end-to-end <metric> on realistic workloads? (§6.2)
Q2 Where does the gain come from? (§6.3, component breakdown)
Q3 What does it cost — memory, CPU, complexity? (§6.4)
Q4 When does it lose? (§6.5, adversarial and edge workloads)
Q4 is the EuroSys credibility section: a paper that measures its own worst
case defuses the reviewer whose job is to find it.
- Every figure caption states the takeaway, not just the axes.
- Numbers in prose carry their conditions: "2.1x on the write-heavy trace at
p99", never bare "2.1x better".
- Banned without qualification: "significantly", "dramatically", "orders of
magnitude", and any superlative the data does not literally show.
Sentence surgery
| Draft reflex |
EuroSys register |
| "X is a critical challenge in modern datacenters" |
Open with the measured symptom, not the genre claim |
| "significantly reduces latency" |
"reduces p99 by 38% on trace T at 85% load" |
| "our novel approach" |
Name the mechanism; novelty is the reviewer's verdict |
| "due to space constraints, details are omitted" |
Point to the artifact or cut the claim |
| "we believe this generalizes" |
State the condition under which it generalizes, or drop it |
| "as shown in Figure 6" (alone) |
"...which isolates the planner's contribution (Fig. 6)" |
Revision passes that pay at this venue
- Retell pass — after each design subsection, write its three-sentence
PC-meeting summary; if you cannot, the subsection is not done.
- Number pass — every performance number in prose gets its conditions
attached or gets deleted; captions get takeaways.
- Skeptic pass — read only §Evaluation as a hostile reviewer hunting
untuned baselines and missing worst cases; fix what you find.
- Blind pass — search for lab names, grant strings, first-person
references to prior systems, and telltale cluster hostnames in listings.
- Budget pass — measure section lengths against the 12-page allocation
and rebalance before polishing sentences that will be cut anyway.
Double-blind voice
- Your prior systems appear in third person: "extends Foo [12]" — even when
the extension is obviously yours.
- Deployment anecdotes get de-identified without being falsified: "a European
cloud operator" is fine; invented deployments are fraud.
- Acknowledgments, grant numbers, and lab-specific artifact URLs wait for
camera-ready.
Output format
[Insight sentence] <the one-sentence idea a reviewer should retell>
[Arc audit] pain -> structural gap -> insight -> system -> numbers: present/missing
[Budget skew] <sections over/under the 12-page allocation>
[Claim hygiene] <unscoped numbers and superlatives found>
[Q4 status] <does the evaluation measure where the system loses?>
Source: brycewang-stanford/Awesome-Journal-Skills → EuroSys-Skills/skills/eurosys-writing-style/SKILL.md
1---2name: eurosys-writing-style3description: Use when drafting or revising EuroSys prose — building the problem-to-mechanism arc systems reviewers expect, budgeting the 12 technical pages across design and evaluation, writing figure-first evaluation sections, keeping claims measurement-scoped, and maintaining double-blind voice in the acmart sigplan format.4---567# EuroSys Writing Style89Use this on the manuscript itself. A EuroSys paper succeeds when a broad10systems PC — kernel people, distributed-systems people, cloud and security11people — can each extract the same mechanism and believe the same numbers12within one reading. The two-column `acmart[sigplan]` format and the 12-page13technical budget (EuroSys 2027 CFP, rendered 2026-07-08) reward density that14stays legible, not compression that hides.1516## The load order of a EuroSys introduction17181. The operational pain, stated concretely enough to measure.192. Why the existing abstraction or mechanism structurally cannot fix it —20 named systems, not "prior approaches".213. The insight: the one idea that unlocks the design.224. What was built, and the two or three numbers that prove the idea carries.235. Contributions as verifiable statements, each pointing at a section.2425A reader who stops after page one should be able to state your insight in a26sentence. If the insight sentence does not exist, the problem is the research27framing, not the writing (route to `eurosys-topic-selection`).2829## Page budget that survives review3031| Section | Share of 12 pages | Failure mode when misallocated |32|---|---|---|33| Intro + motivation | ~2 | Motivation essay crowds out the design |34| Design + implementation | ~4.5 | Mechanism described by metaphor, not by structure |35| Evaluation | ~4 | Result dump with no questions being answered |36| Related work + discussion | ~1.5 | Either a stub or a survey; both read badly |3738References are free pages at EuroSys — cite generously and spend zero39technical pages on bibliography anxiety.4041## Design sections that reviewers can retell4243- Name components and keep the names stable; a renamed component is a new44 component to a tired reviewer.45- One architecture figure whose boxes match the subsection structure.46- For each mechanism: the invariant it maintains, the common-case path, the47 failure path, and the cost you pay for it. The cost sentence is what48 separates engineering description from research writing.49- Push code-level detail down to a listing only when the trick *is* the code.5051## Evaluation prose discipline5253Open with the questions, then answer them in order:5455```text56§6 Evaluation. We answer four questions:57 Q1 Does <system> improve end-to-end <metric> on realistic workloads? (§6.2)58 Q2 Where does the gain come from? (§6.3, component breakdown)59 Q3 What does it cost — memory, CPU, complexity? (§6.4)60 Q4 When does it lose? (§6.5, adversarial and edge workloads)61```6263Q4 is the EuroSys credibility section: a paper that measures its own worst64case defuses the reviewer whose job is to find it.6566- Every figure caption states the takeaway, not just the axes.67- Numbers in prose carry their conditions: "2.1x on the write-heavy trace at68 p99", never bare "2.1x better".69- Banned without qualification: "significantly", "dramatically", "orders of70 magnitude", and any superlative the data does not literally show.7172## Sentence surgery7374| Draft reflex | EuroSys register |75|---|---|76| "X is a critical challenge in modern datacenters" | Open with the measured symptom, not the genre claim |77| "significantly reduces latency" | "reduces p99 by 38% on trace T at 85% load" |78| "our novel approach" | Name the mechanism; novelty is the reviewer's verdict |79| "due to space constraints, details are omitted" | Point to the artifact or cut the claim |80| "we believe this generalizes" | State the condition under which it generalizes, or drop it |81| "as shown in Figure 6" (alone) | "...which isolates the planner's contribution (Fig. 6)" |8283## Revision passes that pay at this venue84851. **Retell pass** — after each design subsection, write its three-sentence86 PC-meeting summary; if you cannot, the subsection is not done.872. **Number pass** — every performance number in prose gets its conditions88 attached or gets deleted; captions get takeaways.893. **Skeptic pass** — read only §Evaluation as a hostile reviewer hunting90 untuned baselines and missing worst cases; fix what you find.914. **Blind pass** — search for lab names, grant strings, first-person92 references to prior systems, and telltale cluster hostnames in listings.935. **Budget pass** — measure section lengths against the 12-page allocation94 and rebalance before polishing sentences that will be cut anyway.9596## Double-blind voice9798- Your prior systems appear in third person: "extends Foo [12]" — even when99 the extension is obviously yours.100- Deployment anecdotes get de-identified without being falsified: "a European101 cloud operator" is fine; invented deployments are fraud.102- Acknowledgments, grant numbers, and lab-specific artifact URLs wait for103 camera-ready.104105## Output format106107```text108[Insight sentence] <the one-sentence idea a reviewer should retell>109[Arc audit] pain -> structural gap -> insight -> system -> numbers: present/missing110[Budget skew] <sections over/under the 12-page allocation>111[Claim hygiene] <unscoped numbers and superlatives found>112[Q4 status] <does the evaluation measure where the system loses?>113```114115---116117**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `EuroSys-Skills/skills/eurosys-writing-style/SKILL.md`
thedixitjain