Why are you reading this?

Submitting a paper is easy, but getting a paper accepted is hard...

Writing a paper is like showing someone a beautiful landscape through a window. The landscape (your ideas and results) defines the true value of the view (the paper), but the window (the paper’s presentation) determines how clearly others can see it. A spotless window won’t make the landscape itself more stunning, but a dirty one can easily ruin it.

In this guide, I (Fred) compile and share practical tips and tricks to help you keep your presentation clean and clear, ensuring your work is appreciated for the strength of its ideas rather than hindered by its presentation. This guide is organized as follows:

Types of papers

Before we talk about good papers, what is a paper?

Before talking about presentation, let’s quickly recap what makes a good paper content-wise. In ML-related fields, most papers fall into one of three main categories (omitting reviews and position papers):

• Improving the state of the art (SOTA) for a well-known task. This is the most common (and often the easiest) type of paper to write. However, it can easily feel incremental unless your improvement introduces something meaningfully different. For these papers, the focus is on strong and relevant baselines and rigorous benchmarks.
• Expanding the understanding of existing methods, for example by generalizing a framework, explaining its successes and limitations, identifying new failure cases. Ideally, such insights should be actionable, i.e., they should suggest ways to improve the existing method. These papers are trickier to write, as you must convince reviewers that your findings are both novel and important, and the structure is less clear.
• Introducing a new benchmark (evaulation) or dataset (training) for an existing task. While other types of paper can also introduce new datasets, such papers place the release of the dataset as a central contribution.
• Introducing and addressing a whole new task. In this case, you must compare your method against a naive baseline (ideally several).
• Uncovering a cool, unknown phenomenon. This is more open-ended. An example of such papers could is the Subliminal leanring paper by Anthropic.

Whatever the case, don’t start writing until it’s absolutely clear which of these three categories your project belongs to.

Claim vs Evidence

But what is science? (think about it..)

This is the shortest section of this guide and the most important. A paper is nothing more, and nothing less, than a set of novel claims supported by evidence. Everything else, the writing, the figures, the structure, exists only to make that claim clear and that evidence convincing. If you remember one thing from this guide, let it be this: before writing a single line, ask yourself what is my claim, and what is my evidence? Do not overclaim, and do not include evidence (figures, tables, etc.) that do not support any claim.

Structure

How to structure your paper?

The general structure of a paper is the following:

1. Abstract: A concise summary of the problem, method, and main results. It should clearly state what you did, why it matters, and how well it worked.
2. Introduction: Motivates the problem, highlights its importance, position your approach (just enough to make your contributions clear), and summarizes your key contributions. Make it engaging (maybe use an example) but factual. Typically, the introduction ends with a 3-5 bullet points list of the main contributions. Be careful not to overclaim.
3. Related work: Positions your paper within existing research in more detail. Explain what others have done and how your approach differs or improves on theirs. Structure your related work using 2-4 paragraphs (i.e., using \paragraph{}), each covering a topic. For instance, if you introduce a new transformer architecture for NLP, you might have a paragraph on transformers, and one on NLP.
4. Background: Introduces key concepts, notations, or models needed to understand your method. Keep it short and directly relevant.
5. Method: The technical core. Clearly describe your approach, equations, and design choices so that others could reproduce your results.
6. Experiments: Explain how you evaluate your method: datasets, baselines, metrics, implementation details, and compute infrastructure (using \paragraph{}). Justify every choice. In general, we should always have a quantitative and a qualitative evaluation. For instance, we compare our proposed methods using metrics and using qualitative examples (both good and bad; showing failure modes is usually well appreciated, sometimes even required).
7. Results: Present your findings using tables and figures. Highlight trends and discuss what the results demonstrate, not just the numbers.
8. Discussion: Interpret the results: why they matter, what insights they reveal, and how they relate to your hypotheses or prior work.
9. Limitations: Honestly acknowledge weaknesses and open questions. This shows maturity and builds reviewer trust.
10. Conclusion: Summarize the key takeaways and possible future directions. End with what the reader should remember.

Depending on the size and complexity of the paper, some sections can be merged. The minimal (incompressible) structure is:

1. Abstract
2. Introduction
3. Related Work
4. Method (merged with background)
5. Experiments (merges with results)
6. Discussion (merges with conclusion and limitations)

The section titles are flexible, and the position of the related work section is flexible (see Citation and References for more details).

% At the end of the introduction — contributions list
Our main contributions are as follows:
\begin{itemize}
  \item We propose a novel framework for ...
  \item We provide theoretical guarantees showing that ...
  \item We evaluate our method on three benchmarks and show that ...
\end{itemize}

% In the related work section — use \paragraph{} for subsections
\section{Related Work}
\label{sec:related_work}

\paragraph{Federated learning.}
Federated learning was introduced by \citet{mcmahan2017communication} ...

\paragraph{Data valuation.}
The problem of assigning value to training data has been studied by ...

Writing Heuristics

Okay nice... but how to actually write a good paper?

Writing a clear and engaging paper is challenging, but many practical heuristics can help. I recommend reading this blog post and this summary of writing tips. For a more practical and detailed set of guidelines, you can find below a collection of useful writing tips compiled by my supervisor Roger Wattenhofer.

Editor

Where to write your paper, and how to collaborate?

We write papers using LaTeX and we use the collaborative online editor Overleaf. If we decide to write a paper for your project, I (Frédéric) will set up the template and invite you to the project. You can use your ETH credentials for Overleaf, as you have access to a free pro account as a student. If you prefer to work using your private account, send me the corresponding email address. The typical structure of the project will be:

my-project/
├─ .gitignore                # must ignore build/ and other compilation artifacts
├─ author_kit_<venue>/       # conference/workshop author kit (style files, templates)
│  ├─ style.sty                  # the style file for the paper
│  ├─ style.bst                  # (optional) the bibliography style file
│  └─ ...
├─ assets/                   # all figures, images, videos, and other media
│  ├─ fig1.pdf                   # figures must be in vector PDF format (no png/jpg/svg)
│  ├─ fig2.pdf
│  └─ ...
├─ main.tex                  # paper source — or main_<venue>.tex if multi-venue
├─ references.bib            # bibliography (single file, shared across venues)
├─ page.md                   # project web page (optional, plain Markdown, no frontmatter)
└─ build/                    # compilation output (must be git-ignored)

A few notes on this structure:

• A project may target multiple venues. Use main_<venue>.tex (e.g., main_aaai.tex, main_iclr.tex) and a separate author_kit_<venue>/ for each.
• references.bib is shared across venues; keep a single canonical copy at the repo root.
• assets/ holds all media (paper figures, web images, videos, etc.). There is no separate figures/ folder.
• build/ must be listed in .gitignore. Never commit compilation artifacts.

There are two useful Overleaf features that you (we) will most likely use:

• Commenting: You can add comment to selected parts of the raw latex code. These comments can be viewed addressed and resolved by the other collaborators. Click on the Review tab at the top right of the webpage to show/hide comments.
• Reviewing: If you want to propose a change to a specific part of the text, you can turn on the Reviewing mode by clicking over the Editing (small pen) button at the top right of the latex code editor. When this mode is on, every change you make will be marked as temporary, and other collaborators can review them before accepting them. This is typically useful toward the end of the writing.

Finally, you can click on the small page logo at the right of the Compile button to see errors and warnings about your latex code. All errors (red) and most warnings (orange) must be addressed before submission. These typically include:

• Broken references
• Double bibliography entries
• Figures overflowing in the margin
• Missing information for a given bibliography.

Formatting guidelines

How to format your paper?

Each conference/workshop provides an author kit along with submission guidelines. Adhering to these formatting rule is crucial, and any modification typically results in a desk rejection (i.e., a rejection based on form rather than content). Before you write anything, read these instructions thoroughly. Typical mistakes include:

• Importing a package that modifies the margin such as \usepackage{geometry}.
• Importing a forbidden package.
• Changing the font size of the main text.
• Misplacing the captions of the tables and figures (typically above for Tables, and below for Figures, but this varies).
• Submitting the appendix along with the main text (sometimes it’s accepted, sometimes not).
• Exceeding the page limit.
• Exceeding the limit for references (yes, you read correctly, some conferences like ICASSP only allow for a single page of references).

In addition, while this is never mentioned explicitly, submitting a paper that does not reach the page limit is a very bad look.

Figures

How to make a good figure?

There are three main types of figures:

• Overview figures: An overview figure is there to present to method. It should look clean, modern, and be place at the top of the second page generally. It must communicate all conceptual novelty clearly, but not more. Avoid implementation details, excessive notation, or low level components. Every visual element should exist to clarify the contribution, and a reader should understand what is new by only looking at the figure.

• Data based figures: Data based figures are derived from experiments and support empirical claims by showing trends or comparisons. Such figure should show a clear trend or conclusion before anything else. Even without knowing what the axes represent, the reader should visually perceive the result. The choice of the figure type should be such that this trend is obvious. This trend must support a specific claim made in the paper, which is explained in the main text and restated explicitly in the caption. Uncertainty should be shown whenever relevant.

• Qualitative examples: This is simply a figure that showcases a qualitative example, such as a generated image, generated text, etc. A paper should always include at least one qualitative example in the main text, plus at least 3 more in the appendix.

Concerning the figures themselves, here are some general guidelines:

• Captions: Figures, tables, and images are powerful because many reviewers focus on them first. Do not hesitate to write extensive captions. A good caption explains everything needed to understand the figure without searching the main text. Ideally, the caption states what is shown, how it was produced, and what conclusion should be drawn.

• Reproducibility and modularity: Figures should be easy to reproduce and modify. Changing a color, label, or scale should take seconds, not hours. A robust setup uses experiments that save data to disk and a separate Python notebook or script that loads this data to generate all figures. Each figure should be implemented as a function with clear arguments, allowing fast iteration and consistent styling.

• Color: Use consistent and colorblind safe color schemes throughout the paper. Prefer muted colors and avoid visual clutter. Color should not be the only way information is encoded; line styles, markers, or annotations should reinforce meaning. Consistency across figures matters more than aesthetic novelty. Please select a color palette from this website and stick to it throughout the paper.

• File format: Always generate and save figures in vector formats such as PDF. Vector graphics remain sharp at any resolution and integrate cleanly into LaTeX or other publishing pipelines. Raster formats should be avoided for plots and diagrams.

• Size and layout: Figures must be generated at the exact size they will appear in the paper. For a two column layout with a total width of 6.75 inches and an inter column space of 0.25 inches, a single column figure should be 3.25 inches wide, while a full width figure should be 6.75 inches wide. Generating figures at the correct size ensures font sizes and line widths match the surrounding text.

• Fonts: Figure fonts should typically be one point smaller than the main paper text. For a 10 pt paper, figures should use 9 pt fonts. Whenever possible, match the font family used in the paper to ensure visual consistency.

Below is an example code snippet for generating figures. I would strongly suggest to create a python notebook to generate all the figures of the paper, where you can defines variables such as color palette, textwidth, etc. globally and quickly generate/iterate/modify all figures at once. See this paper for a few concrete examples of publication-ready figures.

import matplotlib.pyplot as plt

def plot_main_result(x, y, y_err=None, width_in=3.25):
    plt.rcParams.update({
        "font.size": 9,
        "font.family": "serif"
    })

    fig, ax = plt.subplots(figsize=(width_in, 2.2))

    ax.plot(x, y, label="Method A")
    if y_err is not None:
        ax.fill_between(x, y - y_err, y + y_err, alpha=0.2)

    ax.set_xlabel("Training steps")
    ax.set_ylabel("Accuracy")
    ax.legend(frameon=False)
    ax.grid(alpha=0.3)

    fig.tight_layout()
    fig.savefig("main_result.pdf")
    plt.close(fig)

Tables

How to present quantitative results?

Tables are boring, so focus on making them clean and readable. Here are a few rules:

• In latex, we use tabularx tables, not tabular.
• Professional tables do not have vertical lines.
• The horizontal lines are added using \toprule, \midrule, \bottomrule or \cmidrule (for partial lines). These come from the booktabs package.
• The font size should be equal or 1 point smaller than the main text. Do not reduce it more to make it fit.
• You might use the multirow package to merge cells.
• Tables should span the text width. Exceptions are:
  • The paper uses a two columns format. In that cases, tables can either span one or two columns.
  • Your table simply does not have enough columns to span the entire paper. In that case you might use \wraptable from wrapfigpackage.

\documentclass{article}
\usepackage{tabularx}
\usepackage{booktabs}
\usepackage{multirow}

\begin{document}
\begin{table}[h]
\centering
\small % usually 9 points, compared to 10 points for the default article font size
\setlength{\tabcolsep}{3pt} % narrower columns
\renewcommand{\arraystretch}{0.9} % 10% shorter rows
\caption{Famous Datasets.} % Might be placed below the table sometimes. Check formatting guidelines.

\begin{tabularx}{0.99\textwidth}{X X p{1cm}} %X equally divides the remaining space (i.e., 0.99\textwidth - 1cm)
\toprule
Dataset       & Description           & Size        \\ \midrule
MNIST         & Handwritten digits    & 70,000      \\
CIFAR-10      & Tiny colored images   & 60,000      \\
ImageNet      & Everything ever       & 14,197,122  \\
IMDB Reviews  & People yelling online & 50,000      \\
Titanic       & Who survived?         & 891         \\
\bottomrule
\end{tabularx}

\end{table}
\end{document}

Labeling

How can I refer to my own figures in the text?

All figures, numbered equations, and tables should be referred to in the main text at least once. To do so, use the cleveref package (\usepackage[capitalize]{cleveref} in the preamble). In the figure/table/equation environment or under the section title, add a label with the appropriate prefix. Then, in the main text, refer to any labeled object using \cref{X}.

• Figure: fig: (e.g. \label{fig:overview})
• Table: tab: (e.g. \label{tab:results})
• Equation: eq: (e.g. \label{eq:loss})
• Section: sec: (e.g. \label{sec:method})
• Appendix: app: (e.g. \label{app:additional_results})

\usepackage[capitalize]{cleveref}

% Labeling
\label{fig:overview}   % in a figure environment
\label{eq:loss}        % after an equation

% Referencing
As shown in \cref{fig:overview}, ...
We minimize \cref{eq:loss} using Adam.

Citation and References

How to cite relevant literature?

References are the roots of your paper, weak roots won’t survive the storm of reviews. Two key aspects: what to cite and how to cite.

What to cite

• In the related work: cite seminal papers and the most relevant work to your contribution. If you build directly on a previous paper, cite it last and make similarities/differences explicit.
• In experiments: cite every asset you use (datasets, models, baselines, algorithms). For foundation models, see my model cards research note for canonical citations. Feel free to mention if a foundation model is missing, and I will add it to the collection.
• Tone: always praise competitors and cite with a positive tone, even if your method outperforms theirs.

Related work structure

• Organize into thematic paragraphs (e.g., one on transformers, one on segmentation). Don’t just copy another paper’s related work.
• Placement: after the introduction (if your method depends on it) or before the conclusion (if independent). A short version in the main text + extended version in the appendix is also fine.

How to cite (LaTeX) To cite in LaTeX, you must include a BibTeX entry in your references.bib file (see the reference formatting guide for the exact format, ensure all entries have a consistent style.), then use one of the following commands:

• \citep{key} — parenthetical: (Smith et al., 2024)
• \citet{key} — textual: Smith et al. (2024)
• For most style files, \cite = \citep.

% \citep — parenthetical citation (most common)
Recent work has explored scalable federated learning \citep{smith2024scalable}.

% \citet — textual citation (authors as part of the sentence)
\citet{vaswani2017attention} introduced the Transformer architecture.

% Multiple citations
Several methods have been proposed \citep{smith2024scalable, vaswani2017attention}.

Checklist before submitting

What to check before you hit submit?

• Use a grammar correcting tool such as Grammarly/Writeful directly in overleaf.
• Proofread for grammar and style (you should read through the full paper at least 3 times). This includes:
  • The main text.
  • The title and section titles.
  • The figures and tables.
• Ensure formatting follows conference guidelines. In particular:
  • Check that you didn’t inadvertently change the font size, paper margin, style file, etc.
  • Check page and reference limits.
  • Check that you didn’t add any forbidden package.
• Check that there are no more overleaf warning or error. If yes, address them.
• Create an account on the submission website (typically OpenReview or Microsoft CMT) to be registered as an author.
• Reviewers will use LLMs to review your paper, it’s a new reality. But you can also take advantage of them by asking a s trongLLM to review your paper using the prompt below (feel free to improve it).

You are an experienced ML reviewer for a top-tier venue (NeurIPS, ICML, ICLR).
Review the attached paper thoroughly. Be constructive but critical.

Evaluate each of the following dimensions and give specific, actionable feedback:

1. **Claims vs Evidence** — Are all claims novel and clearly supported by evidence? Are there any overclaims or unsupported statements?

2. **Structure & Flow** — Does the paper follow a logical structure (Abstract → Introduction → Related Work → Method → Experiments → Discussion → Conclusion)? Is anything missing or misplaced?

3. **Writing Quality** — Check for:
   - Long or convoluted sentences
   - Ambiguous pronouns
   - Informal language or contracted forms (don't, can't)
   - Forbidden words (very, extremely, obvious, trivial)
   - Synonyms used for technical terms (should always be consistent)
   - Missing or broken references

4. **Introduction** — Does it clearly motivate the problem, state contributions (ideally as bullet points), and avoid self-praise? Is there a figure on the first page?

5. **Related Work** — Is it organized into thematic paragraphs? Does it cite seminal work and position the paper clearly? Is the tone positive toward competitors? Is there any obvious missing citation?

6. **Figures & Tables** — Are all figures and tables referenced in the text? Are captions self-contained and informative? Are figures in vector format? Do tables use booktabs style (no vertical lines)?

7. **Experiments** — Are baselines relevant and sufficient? Are all assets (datasets, models, algorithms) cited? Is there both quantitative and qualitative evaluation? Are implementation details and compute infrastructure mentioned?

8. **Labeling & References** — Are all figures, tables, and equations labeled with proper prefixes (fig:, tab:, eq:, sec:, app:) and referenced using \cref? Are citation commands correct (\citep vs \citet)?

9. **Limitations** — Does the paper honestly acknowledge weaknesses?

10. **Formatting** — Does the paper appear to follow the venue's formatting guidelines (margins, font size, page limit, caption placement)?

For each dimension, output:
- ✅ Good: [what works well]
- ⚠️ Issues: [specific problems with line references if possible]
- 💡 Suggestions: [concrete improvements]

End with an overall assessment: Strong Accept / Accept / Weak Accept / Borderline / Weak Reject / Reject, with a 2-sentence justification.

Additional resources

Where to learn more?

• A Practical Guide to Format Your References: My BibTeX conventions, entry templates, and citation key format.
• Foundation Models: Canonical citations for major frontier and open-weights models.
• Neel Nanda’s blog post: Highly opinionated advice on how to write ML papers (at least read the TL;DR).
• Jakob N. Foerster’s blog post: Similar practical tips.xs