Writing Rebuttals and Responses to Reviewers

This page describes the MItHRIL's standard approach for responding to reviewer and editor feedback during a revise-and-resubmit or major revision cycle and should be treated as the default format for future journal and conference rebuttals from the lab, unless a venue's own template requires otherwise.

Why a table, not a letter

A traditional prose-style response letter (one long document with reviewer text quoted inline, followed by paragraphs of response) reads well but is hard to audit: it is difficult for an editor, a co-author, or future-you to confirm that every individual point raised was actually addressed, and comments risk being bundled together or answered only partially.

Instead, structure the response as a three-column table, with one row per individual criticism:

Reviewer Comment	Author Response	Manuscript Changes

• Reviewer Comment — the specific point raised, quoted or closely paraphrased.
• Author Response — how you addressed it, written to the reviewer in first person plural ("we").
• Manuscript Changes — the exact text added, changed, or removed, ideally quoted directly from the revised manuscript, with a section reference (e.g., "Section 4.4"). Leave this column empty (an em dash is fine) for comments that required no manuscript change, e.g. a reviewer's positive remark you are simply thanking them for.

This format lets an editor scan down the left column to confirm every comment was addressed, scan the middle column to see how, and scan the right column to verify the change actually happened.

One row per criticism, not per reviewer

The single biggest difference between this format and a prose letter: do not bundle multiple criticisms into one row, even if a reviewer raised them in the same paragraph. Reviewers often pack several distinct concerns into a single block of review text (e.g., "Major Comment 2" might raise a methodological issue and ask a clarifying question and suggest a citation). Each of those becomes its own row.

Conversely, don't split a single point across multiple rows just to increase row count — if a reviewer makes one point and the response naturally requires citing two manuscript locations, that is still one row with two items in the Manuscript Changes cell.

A useful test: if you can imagine the editor asking "did they address X?" as a standalone yes/no question, X deserves its own row.

Document structure

1. Front matter — a short cover section above the table: manuscript ID and title, salutation to the editor, a brief paragraph noting that the table below addresses each comment individually and that a tracked-changes manuscript is attached, and a signature block.
2. Section header rows — inside the table, use a shaded, full-width row (spanning all three columns) to mark the start of each reviewer's or editor's comments, e.g. "Reviewer 2 (Recommendation: Major Revision)". This keeps a long table navigable without leaving the table structure.
3. Editor comments first, in the order they were received (Senior AE, then AE), followed by each numbered reviewer in order (R1, R2, R3, …).
4. Within a reviewer's section, preserve their own organization if they used one (e.g., "Major Comments" vs. "Minor Comments," or their own subheadings like "Terminology," "Methods," "Results"). Use section header rows for these sub-groupings too if a reviewer's comments are long enough to warrant it.
5. Editor recommendation lists — when an AE provides a numbered list of required changes, break each numbered item into its own row, even though they arrived as one list. This is usually the densest, highest-priority part of the response and benefits most from being explicit.

What goes in each column

Reviewer Comment column: - Quote the reviewer directly where practical; paraphrase only long or meandering comments, and paraphrase faithfully rather than summarizing away the specific concern. - If a reviewer's comment references a section or line number, keep that reference — it helps the editor locate context quickly. - Tag the comment with its origin label in brackets when useful, e.g. [Major 2], [Minor 6], [Terminology 3], matching the reviewer's own numbering so it's easy to cross-reference against the original review.

Author Response column: - Written to the reviewer, first person plural, present or past tense as appropriate ("We thank the reviewer for this comment. We have added…"). - Thank the reviewer specifically for what they raised — generic thanks read as boilerplate; specific thanks ("which highlighted an important ambiguity in our use of X") signal you engaged with the substance. - State clearly what you did, not just that you did something. "We revised the introduction" is weaker than "We removed the claim and reviewed the manuscript for similar overclaiming." - Where you disagree with a reviewer or only partially act on a suggestion, say so plainly and give your reasoning — don't silently do something different from what was asked without explaining why. - Where one response addresses multiple reviewers' related comments, it's fine to note that explicitly ("as also raised in Reviewer 3's Comment 12") rather than duplicating a near-identical response.

Manuscript Changes column: - Quote the actual revised sentence(s), not a description of the change. "We clarified the force threshold process" belongs in the Author Response column; the actual new sentence belongs here. - Include a section/subsection reference for every entry (e.g., "Section 4.4 (Interaction Control Subsystem)"). - For changes spanning multiple locations (e.g., a terminology fix applied throughout), it's fine to give one representative quote plus a note like "and terminology revised throughout" rather than quoting every instance. - Leave empty (em dash) when a comment required no textual change — e.g., acknowledgement-only comments, or comments answered entirely within the Author Response column (such as clarifying methodology that was already correct in the manuscript).

Tone and framing

• Thank reviewers for comments that improved the paper, but don't over-thank comments that didn't — calibrate warmth to how much the comment actually helped.
• When a review raises a serious framing issue (e.g., an editor's concern that a claim is overstated), the response should show the reasoning behind the fix, not just announce that a fix was made. This is what convinces an editor the underlying issue was understood, not just patched over.
• Never simply state "Fixed" or "Addressed" with no further detail — this is the fastest way to make a response letter look perfunctory and invites a reviewer to re-raise the same point next round.
• Where several reviewers raise a similar concern from different angles, address each on its own terms in its own row rather than copy-pasting one response — a reviewer whose specific wording was ignored in favour of a generic reused answer will notice.

Building the table

For lab members producing one of these: extract the reviewer PDF or letter into its individual comments first (a numbered or bulleted outline works well), draft the Author Response and Manuscript Changes content against your revised manuscript, then assemble into the table last. Trying to draft directly into table cells tends to produce responses that are too short, since the format doesn't visually "invite" the kind of explanatory prose a real response often needs — draft the substance first, then fit it to the row.

When producing the actual .docx deliverable, keep column widths even (roughly a third each) and use a light shading only for header and section-title rows, not content rows, so the document stays easy to scan when printed or viewed at reduced zoom.

Related pages

Rebuttal Letter Template (docx)