HackMD
    • Sharing Link copied
    • /edit
    • View mode
      • Edit mode
      • View mode
      • Book mode
      • Slide mode
      Edit mode View mode Book mode Slide mode
    • Customize slides
    • Note Permission
    • Read
      • Owners
      • Signed-in users
      • Everyone
      Owners Signed-in users Everyone
    • Write
      • Owners
      • Signed-in users
      • Everyone
      Owners Signed-in users Everyone
    • Commenting & Invitee
    • Publishing
      Please check the box to agree to the Community Guidelines.
      Everyone on the web can find and read all notes of this public team.
      After the note is published, everyone on the web can find and read this note.
      See all published notes on profile page.
    • Commenting Enable
      Disabled Forbidden Owners Signed-in users Everyone
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Invitee
    • No invitee
    • Options
    • Versions and GitHub Sync
    • Transfer ownership
    • Delete this note
    • Note settings
    • Template
    • Insert from template
    • Export
    • Dropbox
    • Google Drive Export to Google Drive
    • Gist
    • Import
    • Dropbox
    • Google Drive Import from Google Drive
    • Gist
    • Clipboard
    • Download
    • Markdown
    • HTML
    • Raw HTML
Menu Note settings Sharing Help
Menu
Options
Versions and GitHub Sync Transfer ownership Delete this note
Export
Dropbox Google Drive Export to Google Drive Gist
Import
Dropbox Google Drive Import from Google Drive Gist Clipboard
Download
Markdown HTML Raw HTML
Back
Sharing
Sharing Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
Write
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
Comment & Invitee
Publishing
Please check the box to agree to the Community Guidelines.
Everyone on the web can find and read all notes of this public team.
After the note is published, everyone on the web can find and read this note.
See all published notes on profile page.
More (Comment, Invitee)
Commenting Enable
Disabled Forbidden Owners Signed-in users Everyone
Permission
Owners
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Invitee
No invitee
   owned this note    owned this note      
Published Linked with GitHub
Like BookmarkBookmarked
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
# 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) -->

Import from clipboard

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lost their connection.

Create a note from template

Create a note from template

Oops...
This template is not available.


Upgrade

All
  • All
  • Team
No template found.

Create custom template


Upgrade

Delete template

Do you really want to delete this template?

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Forgot password

or

By clicking below, you agree to our terms of service.

Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox

New to HackMD? Sign up

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Tutorials

Book Mode Tutorial

Slide Mode Tutorial

YAML Metadata

Contacts

Facebook

Twitter

Discord

Feedback

Send us email

Resources

Releases

Pricing

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions

Versions and GitHub Sync

Sign in to link this note to GitHub Learn more
This note is not linked with GitHub Learn more
 
Add badge Pull Push GitHub Link Settings
Upgrade now

Version named by    

More Less
  • Edit
  • Delete

Note content is identical to the latest version.
Compare with
    Choose a version
    No search result
    Version not found

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub

      Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

       Sign in to GitHub

      HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Available push count

      Upgrade

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Upgrade

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully