The usual advice regarding rebuttals: - Be concise. Program committee members have 20 rebuttals to read. - Make it easy to find information. Have section titles. - Do not be confrontational. Show you are reasonable authors and that it will be a pleasure to work with you during the shepherding. I have seen borderline papers be rejected because the authors were too unreasonable in their rebuttal. - If a reviewer missed a point, it probably means it was not clear. Just clarify and don't comment on the reviewer's lack of intelligence. - Have someone proofread your text. - Do not quote the criticisms from the reviews. No need t have the PC members read negative points an extra time. Instead, label your section with the positive answer to the point. But still make sure people can easily find the info. Do not say "it may seem trivial but it was hard" Do not say "reviewer XXX asks if..." Just give the answer. - Always be positive. For anythign you say, ask yourself if you can't remove a negative spin. The glass is always half full. Which doesn't mean it's not OK to acknowledge limitations. I know, it's a tricky act of balance. - Just address the point, even if you think they're not relevant. Don't whine. Don't complain that you could not address XXX because it involves too much work. No speculation followed by rebuttals, just assertions. Don't do science fiction " we could do this, but then this bad thing would happen" Directly say that this would lead to bad things. - if a reviewer asks for info, don't refer them to another paper: provide the info! the organization should be a flat hierarchy. with one twist: you can have N top level points where only the last point ("Misc.") has subpoints. Don't mention a final version: you imply it's already accepted. A good compromise is to say "a revised version". - Make sure you save your reviews somewhere. It's unclear how long the Siggraph system makes them available and you might be to read them again when working on a revised version in the sad and unlikely case where your paper gets rejected. - address all points, but make sure information is easy to find. you don't know which points are important to reviewers. Plus if you address most points but omit ones, people might think you have something to hide there. - organize by topic, but put reviewer # in section title - maybe have 3 paragraphs for major issues, then a big misc. list - don't apologize all the time - avoid speculating on possible future work. Stick to the positive message about your current submission - avoid long tedious intros (thank you blah blah.... we will address blah blah...). Maybe simply: we thank the reviewers for their thorough comments. We all know the drill. Yes this is a rebuttal, yes you are going to address points, yes you are willing to revise the paper for the final version You can say how you organized your rebuttals: we address a few major poinst first and then the discussion is organized by reviewer # - no conclusion. No "we'll be happy to address further questions". Again, those folks are busy. - Don't state negative points such as "we are incapable of writing a decent paper and our submission made it impossible to understand what we do. We are miserable insects and deserve to be swept away from the surface of the earth." - start by points that are both important and can be won. - don't quote positive reviews either (I mostly talk about opinions here, not so much technical points). As a PC member, it irritates me when authors cherry-pick positive comments, misrepresent the overall evaluation and play reviewers against one another. Maybe this can be done in a more subtle manner as part of an argument saying "as reviewer #XXX points out, this problem has been open blah blah" And note that you'll tempted to quote positive reviews only if the opinions are split. So as a general rule, do not quote reviews, except to push a positive technical point that might have been missed by other reviewers: "blah blah, as noted by reviewer XXX" opinion vs. technical points. if they ask for information, provide the information - Don't hesitate to code and experiment. Have concrete numbers to address issues. - don't say "we are working on extension XXX" they will ask you to complete it as a major revision. if you have 99% chances to be rejected given your scores: aybe stil rebut, just to prepare the terrain for your resubmission. But only rebut misconceptions about magnitude of contributon, potential overlap with other work. It's usually not a good idea to provide more details about aspects of your technique that are not uite mature yet. - how much time you should spend: possibly the full four days times 24h this is really really important. -doa last pass on your reviews to verify you have addressed all comments. - avoid "we acknowledge" (which makes it sound like you are at fault) and say "we agree" See also http://www.siggraph.org/s2009/submissions/technical_papers/faqs.php#rebuttal --------- Ramesh's message: some points to keep in mind .. (Fredo's email attached for more) Writing the rebuttal = Sort reviews by question# and by reviewer# to get a better sense of the overall feedback = In the first half of your rebuttal, try to pick the 3 most important questions raised in the reviews and focus on answering them. Do not rebut reviews sequentially line by line. = In the second half, you can try to address secondary topics or topics raised by a single reviewer = Make it easy to read by ensuring every sentence is self-contained (if you refer to a reviewer comment, try to give some context because the PC member wont have patience to cross-check.) Before rebuttal = The reviews are usually scrutinized by primary/secondary before they are are made available to you. So remember that, primary/secondary are either agree with what is in the review or are waiting to see how you respond to the raised issues. Do not be confrontational towards any individual reviewer. = The reviews are in random order. It is nearly impossible to figure out from the reviews which one is from primary/secondary. After rebuttal = Primary/secondary and 3 tertiary reviewers will discuss online your rebuttal during the next week = Your goal at this stage is to give supportive reviewers enough ammunition so that they can convince the others. = You are expected to address only factual errors but you can also use the opportunity to demonstrate that, if the paper is accepted, you are willing to work with the primary/secondary during the revision. So it is ok to admit the weaknesses of the paper and suggest how you will improve the exposition. = Finally, if the scores are low, it is fine to withdraw. A lot of work goes into the review process. You want to be fair to the process and let the reviewers focus on other papers. ("For a paper with low scores, you may also choose to withdraw your paper from the SIGGRAPH review process (by sending a note to papersadmin2008@siggraph.org)." (See more suggestions from Fredo below)