owned this note
owned this note
Published
Linked with GitHub
# Writing a rebuttal for SIGGRAPH
Submitting a manuscript to SIGGRAPH is a *really* big achievement, so congratulations! This post is intended to provide some tips for handling the rebuttal period, an important (but often overlooked) milestone on the road to acceptance.
# Processing review scores and comments
Reviews are released around ~1.5 months following the submission deadline. Each reviewer will independently read your manuscript and assign it one of the following scores:
- Strong <span style="color:green">Accept</span>
- <span style="color:green">Accept</span>
- Borderline <span style="color:green">Accept</span>
- Borderline <span style="color:red">Reject</span>
- <span style="color:red">Reject</span>
- Strong <span style="color:red">Reject</span>
You will generally receive a total of 5 scores, along with each reviewer’s more detailed comments.
It is common for reviewers to settle on borderline scores. You should keep in mind that <span style="color:blue">what is written in the reviews is just as, if not more, important than the scores assigned.</span> While the difference between Borderline Accept and Accept might appear subtle, the accompanying review comments offer a critical window into the mindset and leanings of reviewers. They can also help you identify whether any gaps in understanding or other sticking points might exist, so that you can be sure to address those in your rebuttal.
<span style="color:blue">You should submit a rebuttal even if you received some extremely strong (or extremely weak) scores.</span> Reviewers can (and often will!) change their minds after reading what other reviewers have to say. Carefully parsing through those comments can help you pinpoint the additional details or context needed to solidify the views of those reviewers leaning toward acceptance, and allay the concerns of those with less favorable views. Leaving questions unanswered by not submitting a rebuttal might risk making otherwise positive reviewers reconsider their support. You should therefore treat all questions and concerns raised as significant and worthy of being addressed.
As you process through the reviews, if you find yourself frustrated by the direction of a particular comment, try to give the reviewer the benefit of the doubt and assume that something in your manuscript was simply misunderstood. Although it is natural to want to spring to the defense when it feels like the work you invested so much into is under attack, you should take a step back and remember that reviewers are on the same side as you: we all share the common goal of wanting to see high-quality papers in our community get published.
# Tackling the rebuttal writing
While no single approach fits all cases, the plan outlined below may help you focus your own rebuttal writing.
## (1) Identifying action items
Start by carefully reading through each review, writing down each of the questions and comments that have been raised.
An approach that can be quite effective is to copy the entirety of each review into a single document, and try breaking down the text into **action items**. For example:
>I thought that the method was interesting, but it lacked X and I am confused about Y. Also, in experiment Z, did the authors assume a and b?
```
- Action item – address lack of X
- Action item – address confusion resulting from Y
- Action item – explain assumptions in experiment Z
```
There is likely going to be overlap across reviews, so consider grouping similar points together as you compile your list. You should keep track of which reviewers raised each point as it helpful to directly address those reviewers in your responses.
## (2) Drafting responses
After you’ve teased out the various action items implied by the review comments, you need to start drafting responses for each point. Some items might be easier to address than others. For example, a question about what you did in an experiment might be considered low-hanging fruit – a chance for you to clarify technical details and hopefully convey the robustness of your experiments. On the other hand, you may find yourself struggling to answer certain other questions. That is okay – the rebuttal is an opportunity for you to <span style="color:blue">deeply reflect on the merits of your work</span>, so a fair amount of time spent in contemplation should be considered natural.
<!-- <span style="color:blue">temp</span> -->
Nevertheless, time is of the essence, so the most important thing to do is just start! Begin jotting down notes, even if incomplete, for each of the action items. A shared document where you can work simultaneously (e.g., Google Docs) is a great way to <span style="color:blue">collaborate and iterate with your co-authors</span>. Tagging each other within the document to escalate items, jumping on quick calls to brainstorm, etc. can all be effective tools for navigating this process.
By the time the reviewers read your rebuttal, they will have forgotten many of details of your paper as well as their own reviews. It is therefore important to ensure that your <span style="color:blue">rebuttal responses are **skimmable** and **self-contained**</span>. It should be clear what and who you are addressing, and relevant details should be summarized. For illustrative purposes, here is a response I wrote in my rebuttal for Point2Mesh [SIGGRAPH 2020]:
> #### Preservation of Genus (R2 / R5)
> R2 correctly pointed out that in the completion comparison we use the convex hull as an initial mesh which implicitly provides the correct genus to our approach. In this sense, the comparison is not entirely fair, since the other approaches do not use this information which gives an advantage for hole filling. Indeed, this can also be viewed as a benefit of our approach, since preserving the initial genus provides control, which is lacking in competing methods. Of course, in scenarios where the genus is unknown and ambiguous -- the initial mesh estimation (e.g., alpha shape or poisson) can fail to estimate the correct genus. We will stress these points in the comparison and reiterate in the conclusions.
First, the title/section header summarizes the concern of the reviewers. Note also how the title emphasizes a positive aspect of our work (in that Point2Mesh preserves the genus, which is in fact an advantage). An alternative title, such as “Initial mesh gives unfair advantage in completion”, while acceptable might have unnecessarily injected a negative connotation.
The response that follows, in a short paragraph, allows the reader to tell what question is being answered without needing to refer to the original reviews. Additionally, the response acknowledges potential limitations or drawbacks; in this case, we noted that correctly estimating the initial genus is necessary.
## (3) Preparing and organizing the rebuttal
Many rebuttals take on the following structure:
**A. ` Formalities:`** You may begin by courteously thanking the reviewers for taking the time to review your submission. Keep this part *short and sweet*.
**B. `Opener:`** Depending on the specific circumstances of your paper, you might want to take the opportunity to address all reviewers in an opening paragraph or two. For example, if you received borderline or negative scores that you believe resulted from a misunderstanding, clearing that up upfront might be best. Similarly, if you think that a significant technical contribution was overlooked by the reviewers, reiterating the contribution upfront could be a good idea. Confer with your co-authors and decide on what is most appropriate for your rebuttal.
**C. `Responses:`** By carefully reading and analyzing the reviewer comments, and thoughtfully preparing your responses, it is expected that you will have internalized the overarching themes and concerns of the reviewers. You likely will have noticed recurring patterns (e.g., did more than one reviewer misunderstand or miss completely an important point you assumed was clear in your text?) or other items highlighted by multiple reviewers. You should prioritize the ordering of your responses accordingly. Operating under the assumption that the attention span of reviewers will diminish over the course of reading your rebuttal, you should <span style="color:blue">organize the rebuttal such that the most important points you want to make show up early on.</span>
### Additional points to keep in mind when preparing the rebuttal:
- Be mindful of the tone of your responses. Consider your rebuttal similar to a Q&A or objective discussion of your work.
- As mentioned, try not to let the emotions surrounding your investment in your paper prevent you from conducting your communications in a professional manner. <span style="color:blue">Do not be rude, condescending, or confrontational!</span> This will benefit nobody. Even if you are absolutely convinced that a reviewer is “wrong”, *take the higher ground*.
- Be careful not to liberally paraphrase, recharacterize, or misrepresent the comments of the reviewers. Directly quoting a reviewer to argue your position should also be avoided, as this may be perceived as you pitting reviewers against each other.
- It may be appropriate to offer to conduct additional experiments for the final version of the manuscript in response to points raised by the reviewers. However, if your paper is accepted, keep in mind that the acceptance may be conditioned on whatever you promise in the rebuttal, so make sure you are prepared to deliver!
## Helpful resources
- [Fredo Durand - Rebuttal Advice](http://people.csail.mit.edu/fredo/rebuttal_advice.txt)
- [Aaron Hertzmann - Technical Paper Rebuttals Aren’t Just For “Factual Errors”](https://aaronhertzmann.com/2020/07/13/rebuttals.html)
- [Li-Yi Wei - How to do Rebuttal](https://blog.liyiwei.org/?p=284)
- [Matt Keeter - Writing a SIGGRAPH paper (for fun)](https://www.mattkeeter.com/projects/siggraph/)
- [Wojciech Jarosz - Common Mistakes in Technical Writing](https://cs.dartmouth.edu/wjarosz/writing.html)
<!-- Other related resources:
- [How to Get Your SIGGRAPH Paper Rejected](https://www.ee.columbia.edu/~sfchang/course/svia-F03/papers/siggraph-reject-how.htm) -->