# Paper presentations

In groups of two you will lead one lecture, presenting a few related papers and
guiding the discussion. We will have presentations most Wednesdays and Fridays.
Please sign up for a presentation slot by **Monday, September 9**; see the
[calendar](../schedule/lectures.md) for the topic and papers for each slot.

## Presentation tips

Research papers are written for a very specific audience, different from (and
much narrower than) our class. Papers published in conferences---most papers in
computer science---are also subject to tight page limits and are typically
extremely condensed; many key things are left unsaid. (Here is a useful
[guide](https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPaper.pdf) to
reading papers.) When presenting a paper in class, you should not try to cover
every last detail in the paper. Instead, you should try to unpack the paper so
that it is easier to understand, expanding on the motivation, adding examples,
comparing concepts across papers, etc.

Here are a few specific things to keep in mind when presenting a paper.

- **Make sure the high-level picture is clear.** Make sure to explain the
  problem the paper is trying to solve, the setting, and as much of the
  motivation behind the paper as possible.
- **Don't spend the whole time presenting technical details.** For instance, it
  is probably not interesting for the class to spend the whole presentation
  talking about the technical details in a single proof.
- **You don't have to present the whole paper.** It is simply not possible to
  present every detail in the span of one lecture. For some papers, it may not
  even be possible to present each main contribution. Focus on the one or two
  most important contributions (as decided by yourself). If the paper first
  discusses a "core" or "basic" version, and then later adds on a bunch of
  advanced extensions, *focus on the core version*.
- **Give as many examples as you can.** Most research papers are extremely
  condensed, and do not have nearly enough examples. Present as many examples as
  you can. Your examples don't need to be drawn from the paper---small examples
  are the most useful, as simple as possible.
- **Keep the class background in mind.** Our class has students from a variety
  of backgrounds; try to keep this in mind. It's better to briefly explain a
  technical term if you are not sure everyone knows what it means. You should
  assume that everyone in the class has basic familiarity with the paper (say,
  assume everyone spent about 30-45 minutes reading the paper before class).

## FAQ

- **How should presenters prepare?**

The presenters should meet with me **one week before** their presentation to
discuss an outline of what you will be presenting.

- **How long should presentations be?**

Each presentation should be at least **60 minutes**, leaving the remainder of
the time for a wrap-up discussion. It's fine to be a few minutes under, but if
you think you will finish more than 5 minutes early you should cover more
material.

- **Can we use visual aids?**

You can use the chalkboard and/or slides for your presentation.

- **How should non-presenters prepare?**

**Before** every presentation, all students are expected to read the papers
closely and understand their significance, including (a) the main problems, (b)
the primary contributions, and (c) how the technical solution. Of course, you
are also expected to attend discussions and actively participate in the
discussion.

- **We wanted to present about XYZ, but another group is presenting!**

While we will try to accommodate everyone's interests, we may need to
adjust the selections for better balance and coverage. Consider picking a
different topic---maybe you'll learn something new!

- **Can we present other papers instead?** 

If you want to present different papers on the same topic, or change the topic
entirely, please talk to me first. Note that the papers have been selected to be
related and focused on a specific topic. There is an additional list of
suggested papers [here](../resources/readings.md).
