Skip to main content

25. After rejection

Most first papers are rejected. *ACL main-conference acceptance rates sit around a quarter, so rejection is the modal outcome, not a verdict on you or your future — almost every researcher you admire has a drawer full of rejection letters they later learned more from than from their acceptances. The reviews sting first and help second. This chapter is the sibling of After Acceptance: what to do when the decision comes back reject.

First, do nothing​

Read the reviews once, then close the laptop for a day. The urge to fire back a furious response, email the chairs, or rage-post is strong and helps nothing. Reviews you read angry look different from reviews you read calm. Come back when you can treat them as data.

Read the reviews for signal​

The reviews are information, even the bad ones — your job is to separate the signal from the noise.

  • Weight by convergence. A weakness two reviewers independently raise is real and must be addressed. A single reviewer's pet peeve may not be.
  • Sort fixable from fundamental. Be honest about which you got. "Add a baseline," "clarify Section 3," "run another seed" are fixable. "The core claim is not supported by the experiments" is fundamental and needs more than a polish.
  • A misreading is a finding. If a reviewer misunderstood your contribution, the paper was unclear there — that is your fault to fix, not theirs (Reviewer 2 notwithstanding). Even an unfair or AI-flavored review usually contains one true thing; mine it.

Decide: revise, redirect, or rethink​

  • Revise and resubmit when the contribution is sound and the issues are addressable. This is the usual path, and the next section is how it works.
  • Redirect to a better-fit venue when the problem was fit, not quality — a workshop, Findings, a more applied or specialized track. A paper rejected as "too niche for the main track" can be a great fit for a workshop.
  • Rethink when reviewers converge on a fundamental flaw. Sometimes the honest move is a different experiment or a reframed claim, not a resubmission of the same paper with the abstract reworded.

What you should not do is resubmit the identical paper to the next deadline hoping for a kinder draw. Reviewers can tell, the same weaknesses resurface, and — as the next section explains — ARR requires you to disclose the prior version regardless.

How ARR resubmission actually works​

At ARR, the primary route for addressing substantive reviewer requests is revise-and-resubmit, not the in-cycle response (Chapter 23). When you resubmit to a later cycle, three things matter.

  • Acknowledge the previous version — this is not optional. You provide the OpenReview link to the prior submission. "A paper that has been previously submitted but fails to acknowledge the previous version will be desk rejected." Hiding a rejection to get a fresh start is the one move guaranteed to backfire.
  • Write a real revision note. ARR asks for an explanation of revisions that "summarize[s] the changes made and include[s] a point-by-point response indicating how you have addressed each weakness and suggestion listed by each reviewer (or your justifications for not doing some of the revisions)." A color-coded PDF showing what changed makes the reviewers' job — and your case — easier.
  • Choose your reviewers deliberately. You can request the same reviewers, who will focus on whether your revisions addressed their concerns, or all new ones, who do not see the prior reviews until after they submit their own. Same reviewers reward genuine revision and a strong note; new reviewers reset a relationship that went badly. Pick on purpose, not by default.

Make the revision real​

The revision note is a promise, and returning reviewers check it. A note that says "we have added the significance test (Section 5.2)" attached to a paper that still has no significance test is the fastest way to lose the same reviewers twice. Actually do the work — and use the revision as the chance to fix what no reviewer flagged but you now see with fresh distance.

Keep perspective​

  • Rejection is the common case, not failure. Many of the papers in Chapter 27 were rejected somewhere first.
  • The reviews are free expert feedback most people would pay for. Keep a list of what you learned.
  • The biggest predictor of a published paper is an author who revised it and sent it back out. Persistence, not genius, gets most papers in.

Common mistakes​

  • Firing off an angry response to reviewers or chairs. It never helps and the field is small.
  • Resubmitting the identical paper unchanged, hoping for an easier panel.
  • Not disclosing the prior version — an automatic desk reject.
  • A revision note that promises changes the paper does not contain.
  • Addressing only the kind reviewer and ignoring the harsh-but-right one.
  • Giving up after one rejection. The reviews are a map to the next version, not a verdict on the project.

Further reading​