# Paper Rebuttal Tips is twenty eight tips, and two thirds of them are about experiments > A curated guide for writing conference rebuttal responses in AI and large model submissions, organised as review scenarios with a bad answer and a better one. The repository is one readme and a folder of images, and it says up front that its own rules vary by conference. **MLNLP-World/Paper-Rebuttal-Tips** — MLNLP社区用来帮助大家论文Rebuttal的整理仓库。 - Repository: https://github.com/MLNLP-World/Paper-Rebuttal-Tips - Stars: 318 · Forks: 32 - Language: Unknown - License: not declared - Published: 2026-09-18 · Updated: 2026-09-18 · Language: en - Canonical page: https://hysenlabs.com/projects/mlnlp-world-paper-rebuttal-tips ## The whole repository is one readme and a folder of pictures The entire project is three entries at the top level: a gitignore, the readme, and a directory of images. There is no code, no build, no tests, and no licence file. That last absence is more than a formality for a document people are told to use. Without a licence, the default position is that the text and the images belong to the author and are not yours to redistribute, which is worth knowing before you fork it into your own team's notes. The hosting platform reports the primary language as unknown, which is accurate for a repository whose content is one long readme written in Chinese with the images doing the explaining. The reason for that structure is stated in the readme itself, obliquely. A collapsed disclaimer notes that the badges used in the project come from the internet and asks to be contacted if an image copyright is infringed. That is only a relevant sentence if the images are doing work rather than decorating. And they are. Every one of the guide's entries is a screenshot. So the project is a filing cabinet. The readme is the index and the ordering, and the substance lives in the pictures folder, which means the whole thing cannot be searched, diffed meaningfully, translated by a tool, or read by anything that does not render images. ## Twenty eight tips and two thirds of them are about experiments The guide is organised as three categories with a deliberate split in what they cover. The first group is about the argument rather than the results. Seven tips on what the paper claims: that the method is too complicated or a pile of tricks, that the novelty is thin or the work resembles something prior, that the contribution looks like a simple combination of existing techniques, that the contributions are stated unclearly, that the motivation is unclear or the problem is not important enough, that the theoretical analysis is thin, and that the limitations discussion is superficial. The second group is five tips about communication. Insufficient related work, unclear writing, a reviewer who misunderstood the method, a vague low quality negative review, and one general strategy: do not merely promise, act. The third group is sixteen tips about evidence, and it is the largest by a factor of three. Weak baselines, a small improvement margin, an unfair setup, missing ablations, excessive computational cost, large experiments that cannot be finished inside the response window, a small dataset, weak generalisation, missing statistical significance, training data leakage, hyperparameter sensitivity, a badly chosen metric, missing human evaluation, no direct evaluation of intermediate or generation quality, no time-dimension support for a claim about a process that evolves, and finally reproducibility and absent code. That distribution is the most useful thing in the guide. It says that the objections a reviewer raises are mostly about evidence, not about framing, and it says so by counting rather than by asserting. ## Every tip's content is an image Each tip is a collapsed block whose visible line is a bold summary, and the first tip in each category is expanded by default while the rest are closed. Inside each block, after a line break and a centred paragraph, there is no text. There is nothing missing from this rendering. The centred paragraph contains an image, and the image was stripped out of the copy of the readme that has been made machine readable. That has three consequences worth being explicit about. You cannot search this guide. There is no text inside the tips to match a query against, so if you are looking for how to answer a specific reviewer objection you are scrolling. You cannot diff it. If a tip's advice is revised, the change is invisible to anyone reviewing a pull request or tracking the history, because the substance is a raster image replaced wholesale. And you cannot act on it in a tool. An assistant asked to help you write a response cannot read the advice, so the guide is for humans reading it in a browser and not for anything else. The chosen format is also the format that ages worst. Screenshots of text do not reflow, do not scale with your display settings, do not survive a translation pass, and cannot be corrected by anyone other than the person who made them. For a project whose stated purpose is to be reused by a research community across conferences, this is the one design decision that limits how far the advice travels. ## The four part template separates the pitfall from the response Every scenario is described with the same four fields, and the separation is the pedagogical point rather than the labelling. The first field is the reviewer's actual objection. Not a category, but the sentence a reviewer would write. The second is the negative response, described in the project's own framing as the reply that is easy to fall into. This is the part most rebuttal guides omit, and it is the part that teaches the most, because the mistake is invisible to the person making it. The third is the recommended response strategy, framed as more effective rather than as correct. The fourth is a summary of the key point. Three things follow from that structure. First, a tip is diagnosable: you can tell whether you are in that situation without deciding whether you agree with the advice. Second, the bad answer is the reference point, so the guide is not a list of things to say but a list of things to avoid saying. Third, the fourth field being separate from the third implies the strategy is not a script, which is consistent with the general tip in the communication group about acting rather than promising. The framing sentence at the top of the project sets the whole register: a rebuttal is not simply contradicting the reviewer, but reorganising the evidence, clarifying a misunderstanding, filling in an experiment, and making the area chair and the reviewers see that the paper is still worth accepting, all in a very short space. That is a description of a constrained argument, and the slogan reduces it to three words: respect, evidence, clarity, in that order. ## The disclaimer says to check your conference rules before using any of it There is a disclaimer, and it is more useful than disclaimers usually are. It states that every tip is for reference only, is not guaranteed to be correct, and is not guaranteed to apply to every conference, every field, or every reviewing situation. Then it gets specific, which is the part that makes it worth reading. Rules differ by conference on word limits, on whether new experiments may be added, and on whether external links are permitted. The instruction is to defer to the conference's own official statement. That last point has teeth when you look at what the guide recommends. Several tips are answered by running something, and the resource section lists tools that generate rebuttal text. If your conference forbids new experiments or forbids links, the two most useful answers in the guide may both be unavailable to you, and you find that out on the day rather than at proposal time. The disclaimer also states where the content came from: the author's personal experience, material found on the internet, the team's own research practice, and what the author learned from senior colleagues around them. That is an honest statement of provenance and it is also a sample size of one group. It is not a survey, it is not aggregated across conferences, and the tips are written for submissions in artificial intelligence and large model work, as the subtitle says. The category names reflect that: the failure modes are recognisable from any empirical machine learning paper, but the weighting and the phrasing are aimed at one field. ## Five of the eight recommended tools write rebuttals for you The resource section has three tables and the middle one is the interesting one. The first table collects written experience, six entries, five of them from one question and answer platform and one from a developer forum. One of those five is a social post whose two links carry the session-bound tracking parameters that platform appends to shared URLs, which means the links in the guide are the kind that expire. The second table collects tools, workflows, and repositories, eight entries. Reading them: a curated list of rebuttal strategy, an automatic rebuttal workflow packaged as a skill, a dedicated editor for drafting responses, an assistant that turns a paper into a rebuttal, a generator aimed at top machine learning and AI conferences, a general research-writing collection that includes skills and prompts, a hosted site that returns a machine-generated review of your draft, and one more skill repository. Five of the eight produce rebuttal text. That is a tension with the guide's own general tip, which says to act rather than merely promise. Generating a response is precisely a promise, and the quality depends on evidence you have not supplied. It is not an objection to the tools, but it is worth noticing that the section the community reaches for is the one that writes the draft. The third table collects English-language experience by author and source, which is the section most readers outside the Chinese-language community will want first. ## The category anchors and the index disagree about what belongs where Small structural details, but they are the kind that make a long readme navigable or not. Each of the three categories has an explicit anchor: one for innovation and theory, one for communication, one for experiments. So the guide can be linked into at the section a reader cares about rather than only at the top. Each category then ends with a right-aligned link back to the tips index. That is a manual index rather than a generated table of contents, which means it can drift, and it means a reader who lands on tip twenty has no direct route to tip seven other than scrolling up. The index itself is a three column table with one cell per category, each carrying an emoji marker, a tip range, and a one line description of what the category covers. That table is the only place the counts are visible, and it is where the imbalance shows: seven tips, five tips, sixteen tips. The page header repeats the same structure as a row of anchor links to the project's main sections, which are the motivation, the tips, the resource collection, the list of contributors, and the invitation to contribute. That last section is worth flagging for a different reason. The tree contains no licence file, so while the project is explicitly open to pull requests, the terms under which a contribution would be licensed are not stated. ## Conclusion Read this as a checklist rather than a template. Its value is the list of failure modes a reviewer will actually raise, split into what your contribution is, how you explained it, and whether your evidence holds, and the fact that the pitfall and the better response are separated so you can see both. Two limits to keep in mind. The repository says outright that conference rules differ on word limits, new experiments, and external links, and that its content comes from one team's experience rather than from a survey, so treat the category headings as prompts rather than as policy. And there is no licence file, so read it rather than redistributing it. ## FAQ ### How to write a paper rebuttal? The guide frames it as reorganising evidence, clarifying misunderstandings, and filling in experiments in a very short space, rather than as contradicting the reviewer. Its slogan reduces that to respect, evidence, and clarity, and each of its twenty eight scenarios pairs the reviewer's objection with the reply that goes wrong and a more effective response. ### What rebuttal scenarios does Paper Rebuttal Tips cover? Twenty eight, in three groups. Seven concern the argument: an over-complicated method, thin novelty, a contribution that looks like a combination of existing work, unclear contributions, weak motivation, thin theory, and superficial limitations. Five concern communication, including a reviewer who misunderstood the method. Sixteen concern evidence, from weak baselines and unfair setups through to statistical significance, data leakage, and missing code. ### Does Paper Rebuttal Tips apply to every conference? No, and the project says so. Its disclaimer states that the tips are reference only, are not guaranteed correct, and are not guaranteed to fit every conference, field, or reviewing situation, because word limits, permission to add new experiments, and permission to include external links all vary by conference. ### Can I search or reuse the content of Paper Rebuttal Tips? Not easily. Each of the twenty eight entries is a screenshot inside a collapsed block, so the advice itself is not machine readable, searchable, or diffable. The repository also contains no licence file, and the hosting platform reports the licence as unknown, so the default position is that the text and images are not yours to redistribute. ### What tools does Paper Rebuttal Tips recommend? Eight entries across tools, workflows, and repositories, five of which generate rebuttal text: an automatic workflow packaged as a skill, a dedicated drafting editor, a paper-to-rebuttal assistant, a generator aimed at top machine learning conferences, and a hosted site that returns a machine-generated review of your draft. ## Sources - [Issues](https://github.com/MLNLP-World/Paper-Rebuttal-Tips/issues) - [MLNLP-World/Paper-Rebuttal-Tips on GitHub](https://github.com/MLNLP-World/Paper-Rebuttal-Tips) - [README](https://github.com/MLNLP-World/Paper-Rebuttal-Tips/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mlnlp-world-paper-rebuttal-tips