跳到主要内容
知仓学习社ZHICANG

sosp-author-response

Use when drafting a SOSP author response during the pre-PC-meeting rebuttal window, keeping it within the venue's norms — correcting factual errors,…

不碰外部(只输出文字)无严重或高危命中brycewang-stanford/Awesome-Journal-Skills

它会碰到什么

扫了多少1 个文本文件,5 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

SOSP Author Response

Use this when SOSP reviews land and the response window opens. SOSP's response phase

has an unusually narrow charter, stated in the CFP (verified 2026-07-08 for the 2026

cycle): responses exist to correct factual errors in the reviews and to **answer

questions reviewers explicitly posed**. They must not add new experiments or data,

describe work done since submission, or promise follow-up work. Submitting a response

is optional, and while no hard cap is stated, authors are strongly encouraged to stay

under 500 words.

What the response can and cannot do

The response is read by a program committee that will discuss the paper live at a PC

meeting. Its job is to remove false obstacles before that discussion, not to renegotiate

the paper.

| Move | Allowed at SOSP? | Why |

|---|---|---|

| "Review B states we hold the lock across I/O; §4.2 shows it is released before the write" | Yes | Factual correction, cites the submitted text |

| Answering "how does this behave when the log fills?" with what the submission already supports | Yes | Direct reviewer question |

| "We have since run the benchmark on 128 nodes and..." | No | New data after the deadline |

| "We will add a comparison against X in the final version" | No | Promised work |

| Re-arguing novelty against a reviewer's taste judgment | Technically allowed, usually wasted words | Not a factual error |

| Pointing to the supplementary document for detail the reviewer missed | Yes, sparingly | It was part of the submission |

Hour-zero triage

Read all reviews once without drafting anything, then classify every negative point:

  1. Factual error — the review misstates what the paper says or does. Highest

priority; these are the response's reason to exist.

  1. Missed content — the answer is in the paper but the reviewer did not find it.

Respond with a section/figure pointer and one sentence of restatement.

  1. Direct question — answer it crisply from the submitted material.
  2. Judgment call — "not novel enough," "evaluation could be broader." Spend at most

one sentence, or zero; the PC meeting will weigh these, and defensive prose does not

move systems reviewers.

If categories 1-3 are empty, seriously consider not responding: an optional response

that only pushes back on judgments can read worse than silence.

Budgeting 500 words

  • Open with two sentences maximum of thanks and framing; no summary of the paper.
  • Order points by expected impact on the PC discussion, not by reviewer order.
  • Quote the review's exact claim in a few words before rebutting, so a PC member

skimming during the meeting can follow without the full review open.

  • Cite the submission by section, figure, or table number every time — the submitted

PDF is the only evidence you are allowed to use.

Response skeleton (target < 500 words total)

We thank the reviewers. We correct three factual points and answer two questions.

[Factual] Rev A: "the design requires a second network round trip."
It does not: the token is piggybacked on the existing ack (§3.3, Fig. 4).

[Factual] Rev C: "no failure experiments."
§5.4 and Table 6 report crash-restart and partition runs on the same workloads.

[Question] Rev B asked how recovery time scales with log size.
Recovery replays only the tail past the last checkpoint; §4.5 gives the bound
and Fig. 9 measures it at three log sizes.

[Clarification] Rev A read the consistency guarantee as per-object; it is
per-session (§2, invariant I2). The distinction affects the Rev A example: ...

Tone calibration for a single-track PC

Every accepted SOSP paper is discussed in front of the whole committee, so your

response's audience is wider than the three or four people who reviewed it. Write so a

non-reviewer PC member encountering the paper for the first time at the meeting sees

authors who are precise, unrattled, and honest about limits. Concede real weaknesses in

one clean sentence ("The evaluation does not include workload X; the submitted results

cover Y and Z") rather than burying them — a concession you volunteer is a footnote at

the meeting, one you dodge becomes the meeting's topic.

Common failure modes

  • Spending the word budget proportionally to review length instead of review influence.
  • Correcting five trivialities and leaving the one score-driving misreading to last.
  • Smuggling in a new number "for context" — chairs notice, and it taints the compliant

parts of the response.

  • Addressing reviewers by name-like inference ("as the senior reviewer notes...");

reviews are anonymous in both directions.

  • Writing 900 words because no hard limit exists. The 500-word guidance is a signal

about attention at the PC meeting, not a formality.

Output format

[Respond at all?] yes / no (categories 1-3 empty)
[Point map] <review point -> factual error / missed content / question / judgment>
[Word budget] <allocation across points, total target>
[Concession] <the one weakness to own explicitly>
[Compliance check] no new data / no promises / submission-only citations

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。