Complete Guide to Submitting ARR Multi-Round Reviews to EMNLP

ARR and EMNLP Submission Mechanics: Background

ACL Rolling Review (ARR) is the rolling review mechanism adopted by mainstream conferences in natural language processing. ARR officially launched in late 2021 as ACL's (Association for Computational Linguistics) systematic reform of the paper review process for the NLP/CL field. Before ARR, top conferences like ACL, EMNLP, and NAACL each ran their own independent review pipelines. If a paper was rejected at one venue, authors had to resubmit from scratch and wait for an entirely new round of reviews — a massive waste of reviewing resources that also placed excessive burdens on reviewers. ARR's core innovation is the decoupling of review and acceptance: reviews obtained through ARR can be reused across ACL, EMNLP, NAACL, EACL, and other venues. Reviewers only review a paper once, and each conference's program committee makes acceptance decisions on top of existing reviews. After completing the review process through ARR, researchers can choose to "commit" their review results to any of these conferences. This system draws on the rolling review tradition from journal publishing, but its operational details frequently confuse submitters.

Recently on Reddit, a researcher raised a classic question: they wanted to submit their March ARR cycle reviews to EMNLP, but also had a May cycle submission currently in the rebuttal window. This kind of "cross-cycle, multi-version" scenario exposes a persistent gap between ARR's official documentation and the actual OpenReview interface.

Core Issue One: What to Do with an Ongoing May Submission?

The first source of confusion is very practical: if you're planning to commit March reviews, what should you do with your in-progress May submission? Three common approaches are:

• Complete the May rebuttal as normal;
• Withdraw the May submission;
• Do nothing, and simply link to the March submission when committing to EMNLP.

From the perspective of ARR's design, review records from different cycles are independent of each other. March and May belong to separate ARR cycles, each with its own review history and OpenReview link. The act of "committing" to EMNLP means designating one specific ARR submission link as the version under consideration.

Therefore, if you decide to use the March version, you technically don't need to prepare a rebuttal for the May submission. However, note that the same paper should not have multiple active submittable versions at the same time — this could trigger dual submission compliance issues. The safest approach is: once you confirm the March link is usable, proactively withdraw the May submission or let it lapse, avoiding any conflict between the two versions.

An Easily Overlooked Compliance Detail: The Boundaries of Dual Submission

Dual submission is a fundamental line of academic integrity in scholarly publishing, referring to the same paper being submitted simultaneously to two or more independent review processes that could each lead to publication. Under the ARR system, the boundaries of this rule become more complex: different revised versions of the same paper across different ARR cycles technically constitute multiple independent OpenReview submission records. ARR's official position is that if an author has decided to commit a particular cycle's version to a target conference, other still-active ARR submissions of the same paper should be withdrawn — ensuring that only one version is in a conference acceptance decision process at any given time. It's worth noting that "active ARR submission" and "committed to a conference" are two different system states: the former means the paper is still in the ARR review pipeline, while the latter means it has entered a specific conference's acceptance decision stage. When both coexist, the compliance boundary depends on the current program committee's specific interpretation.

ARR has explicit restrictions on "the same paper being in multiple review cycles simultaneously." If the May submission and the March submission are different revised versions of the same paper, you must ensure that ultimately only one version enters the conference commitment process. The "do nothing" option carries potential risk — you need to confirm at the system level that both versions won't simultaneously be recognized as valid submissions.

Core Issue Two: What If You Can't Find the Justification Field?

This is the more technically nuanced issue, and it better reflects the disconnect between documentation and implementation. The ARR author guidelines FAQ clearly states: if you are submitting an earlier cycle's reviews (rather than the most recent version), you must also provide the following two items:

1. A link to the more recent submission;
2. A statement explaining why the more recent reviews are "problematic."

The logic behind this requirement is clear: ARR wants to prevent "review shopping" — an academic integrity issue that has long existed in traditional multi-round submission models, where authors can submit papers to different venues and selectively use the most favorable review results without disclosing the existence of other reviews to the final accepting venue. ARR's justification mechanism is designed precisely to counter this behavior: when authors skip a more recent cycle's reviews and choose to submit an earlier version, the system requires them to proactively explain why, with human review by an Area Chair (AC), enabling the program committee to judge whether the author's choice stems from legitimate technical reasons or strategic selection of better review scores. Requiring a justification is meant to let the AC and program committee scrutinize the reasonableness of this choice.

However, some submitters find that EMNLP's commitment form on OpenReview only asks for an ARR paper link and a PDF upload, with no visible justification text box. The information that official rules require is not matched by a corresponding input field in the actual interface — this discrepancy is not unprecedented across ACL conference submissions.

OpenReview's Technical Characteristics and Form Configuration Issues

OpenReview is currently the most widely used paper submission and review management platform in the NLP, ML, and AI fields. Developed and maintained by a team at the University of Massachusetts Amherst, it has become core infrastructure for top academic conferences including NeurIPS, ICLR, and the ACL conference series. The platform's core advantage lies in its openness — review processes, author responses, and meta-review comments can be selectively made public, increasing transparency. However, OpenReview's highly configurable form system also introduces engineering complexity: form fields for each conference and each cycle must be configured independently and can be dynamically adjusted at any time. This means that ARR's documented specifications and the actual OpenReview deployment for a specific cycle can fall out of sync at any time — missing fields, inconsistent trigger conditions, and outdated description text have all been documented by the community across past submission cycles.

There are typically a few explanations:

• Dynamic form triggering: The justification field may only appear when the system detects that you are indeed submitting an "earlier version" (i.e., a more recent submission of the same paper exists in the system). If the system doesn't detect a conflict, the field won't appear.
• Supplement via comments or by contacting the AC: Some cycles allow submitters to add supplementary information after submission via OpenReview's comment feature, or by directly emailing the Area Chair or program committee.
• Annual form differences: ARR's OpenReview configuration may be tweaked each cycle, and FAQ wording may not perfectly align with the current form.

The most pragmatic approach is: complete the submission using whatever fields are actually present in the interface, then proactively contact the program committee via OpenReview's official email to provide the justification, keeping a written record to avoid future disputes over "failing to provide the required statement."

The Gap Between Rule Documentation and the Operational Platform: A Widespread Pain Point

Beyond the individual case, this type of submission confusion reflects a deeper issue with academic submission systems: strict synchronization between rule documentation, FAQs, and the actual operational platform is often lacking. ARR is a complex rolling mechanism involving multi-cycle, multi-conference, and multi-version mapping — any documentation lag at any point can leave submitters in uncertainty. While OpenReview's high configurability gives conferences flexibility to customize, it also makes consistent enforcement of unified standards more dependent on the accuracy and timeliness of manual configuration.

For researchers currently in a submission cycle, the following points are worth keeping in mind:

• Keep screenshots and email records of all actions: If a conflict arises between rules and the interface, these are the key evidence for protecting your interests;
• Handle cross-cycle submissions early, don't wait until the deadline: Leave enough buffer time for communication and confirmation;
• Leverage community experience: First-hand information from researchers on Reddit and academic forums who have gone through the same process is sometimes more practically useful than official documentation.

Summary

Committing ARR reviews to a target conference may seem like just a few clicks, but when multiple cycles and versions are involved, the ambiguous zones in the rules quickly become apparent. For the typical scenario of "committing March reviews to EMNLP while the May rebuttal is in progress," the core principle is: use only one version, proactively avoid version conflicts, and keep a written record of your justification. In a reality where documentation and platform are not yet fully aligned, proactive communication is always safer than passive waiting.

Key Takeaways