Osdi Review Process

---
name: osdi-review-process
description: Use when reasoning about how an OSDI paper is reviewed and decided — the double-blind HotCRP PC pipeline with no author-response period, the two tracks, conditional acceptance with heavyweight shepherding, co-chair recusal, notification timing, and the Jay Lepreau Best Paper lineage.
---

# OSDI Review Process

Model the pipeline the paper enters at the December deadline. The process facts below
are the OSDI '26 cycle (verified 2026-07-08); OSDI re-decides its process per edition —
'26 itself removed the response period — so read the current CFP's process section
before predicting anything.

## The pipeline, author's-eye view

```text
Dec 11  submission complete on HotCRP (osdi26.usenix.hotcrp.com)
   |    double-blind PC review, typically multi-round:
   |      early round -> low-scoring papers exit with fewer reviews
   |      later round(s) -> surviving papers gather more reviews
   |    online discussion + PC meeting
   |    (no author-response step existed in the '26 cycle)
Mar 26  notification: accept | conditional accept | reject
   |    conditional: shepherd assigned, mandated-change list issued
Jun 9   shepherd-approved final paper due (or the acceptance lapses)
Jul 13  open-access proceedings live as the event opens
```

Round structure and reviewer counts are PC-internal and vary; what is stable is the
consequence: **the first two or three pages decide whether the paper earns the later
rounds**, because early-round reviewers triage a large pile (capped at eight
submissions per author, but multiplied across a big community).

## What "no response period" changes about review

OSDI '26 eliminated the author response. Reading the decision process correctly
means internalizing three shifts:

- **Reviewer misunderstandings are terminal.** A reviewer who misreads the threat
  model or misses the baseline's tuning carries that reading into discussion
  unchallenged. The only defense is prose that cannot be misread
  (`osdi-writing-style`'s objection pass).
- **The PC discussion is where papers are saved or sunk** — by other reviewers, not
  by you. A paper survives when its champion can answer objections *from the paper's
  own text*; write so a champion is armed.
- **Conditional acceptance absorbs the dialogue.** The conversation that a rebuttal
  would have hosted moves after the decision, into shepherding, where it has teeth:
  mandated changes, verified by a named shepherd, on a deadline.

## Conditional acceptance and heavyweight shepherding

OSDI '26 stated the mechanism plainly: some papers are accepted conditionally, and
will be **rejected unless the authors make the changes the PC determined**, completed
by the final-paper deadline and approved by the shepherd. Treat it as:

| Property | Practical meaning |
|---|---|
| The change list is a contract | Scope it line by line; ambiguities are resolved with the shepherd, in writing, early |
| The shepherd is the gatekeeper | Their approval — not your opinion of completion — converts conditional to accepted |
| June 9 is the enforcement date | New experiments mandated in April need the frozen testbed from the review window (`osdi-reproducibility`) |
| It is not a negotiation to reopen | Relitigating the reviews with the shepherd burns the one relationship that can accept the paper |

`osdi-author-response` covers how to run the exchange itself.

## Structural facts worth knowing

- **Two tracks, one PC decision process:** Research and Operational Systems papers
  are reviewed against different evidence expectations (novel design vs deployed
  experience) — know which bar your reviewers were told to apply.
- **Co-chair recusal:** OSDI '26 pre-committed that a submitting co-chair's papers
  are handled exclusively by the other co-chair under the same double-blind
  procedure — an unusually explicit conflict rule worth citing if conflict questions
  arise.
- **Best-paper lineage:** the **Jay Lepreau Best Paper Award** (inaugurated at OSDI
  '08) is selected by the PC from the accepted program; strong artifacts and clean
  claims correlate with it, but it is not something authors apply for.
- **Openness after decision:** accepted papers become free PDFs the day the event
  opens (USENIX open access) — reviews themselves stay confidential; OSDI does not
  publish reviews or decisions OpenReview-style.

## Surviving the triage round

Multi-round PC review means the paper's first job is to not exit early. What
early-round reviewers can actually evaluate in a large pile:

- **Pages 1–2 carry the whole argument** — pain, gap, named idea, headline evidence
  with its cost. A reviewer who stops at page 3 should already be wrong to reject.
- **The evaluation's table of contents** — skimmers check that the strongest
  baseline appears and that a cost/limitations discussion exists before reading any
  numbers; their absence is a triage-round exit.
- **Figure captions as a parallel paper** — early readers walk the figures; captions
  that state takeaways ("recovery flat from 8 to 64 nodes; baselines linear") let
  the skim reach the right conclusion.
- **Formatting smells** — cramped spacing, page-13 spillover, or an appendix where
  none is allowed mark the paper as careless before content is weighed
  (`osdi-submission`).

None of this is gaming; it is writing for the process that actually exists — one
with early exits and no author response to recover from a bad first impression.

## Reading a rejection usefully

Without a response phase, OSDI reviews are the *only* signal you get, so mine them:
recurring phrases across reviewers ("unclear workload realism," "incremental over X")
are the PC-meeting summary leaking through. Sort objections into fixable-by-writing,
fixable-by-experiment, and fit-level; the first two feed a SOSP/NSDI retarget within
months (`osdi-workflow`), the third sends you to `osdi-topic-selection` before any
retarget.

## Decoding the decision letter

Three outcomes, three very different next moves: a **clean accept** still usually
assigns a shepherd for lighter-touch final-version guidance — treat their
suggestions seriously even when not framed as mandates; a **conditional accept** is
a contract with a June enforcement date, decoded in the section above; a **reject**
with substantive, convergent reviews is the system working — the reviews are the
retarget's requirements document — while a reject with thin, scattered reviews
usually means a triage-round exit, and the fix is the paper's first two pages, not
its technical core.

## Output format

```text
[Phase] pre-decision / conditional / accepted / rejected
[Process facts confirmed live] response period? tracks? shepherding wording? (待核实 if unread)
[If pre-decision] top 3 misreadings the text invites (terminal without rebuttal)
[If conditional] change-list scoped? shepherd contact opened? June feasibility
[If rejected] objection triage: writing / experiment / fit + retarget call
```