TL;DR

  • participate alone, or in a team of two
  • bimonthly moodle submissions
  • 2-3 lectures
  • 1 small coding project to support your paper
  • 8-9 LaTeX pages for one person submission, 15-16 pages for two-person submissions
  • 5-6 minutes of presentation per person + questions

Process

  • Try out the project we gave you, e.g., write code that puts your topic to use or reimplements an algorithm you found during your research.
  • Start with a topic and a couple of pointers to research papers about that topic.
  • Expand your knowledge by finding new references.
  • Create your own short paper about the topic, summarizing your findings.
  • Review the papers written by other students and receive feedback on your own paper.
  • Give a presentation to the other students
  • Rewrite the paper based on the feedback.

Writing Papers

The initial references provided with the topic chosen by you are only a first step; in your term paper, try not to summarize everything that’s written therein or in the references’ references. Instead, try to tell an engaging, coherent story about one aspect of the topic. (It helps to image oneself as a novice to the topic, who attends the talks or reads the term papers.) Also, search for further references on your own and point out connections between the various papers you researched.

Please present technologies, e.g., programming languages, with your own words and your own examples. If you merely copy the work of others, this means but one thing: no contribution; you will fail the seminar. This rule does not prevent you from quoting other researchers, however. It does require you to faithfully attribute information to its orginal source, though.

Pick some interesting finding about your research area and focus on explaining that. Start with a motivation of the problem. Illuminate necessary terminology considering both being formally correct, providing informal intuition and concrete examples. Remember, your paper MAY summarize the papers you read, but pure summaries are boring – make sure to relate the summaries to each other and the overall story you want to tell.

LaTeX template will be announced.

In summary:

  • Understand your research area.
  • Summarize your understanding – motivate and define the problem and the solution, provide intuition and give examples.
  • Do not follow the papers you read blindly, but make your own choices with regard to structure, content and emphasis, to make the paper readable.
  • Do not copy text or figures verbatim from existing papers.

Writing Peer Reviews

A peer review has three parts.

The annotated review:

  • Scribble on the paper your thoughts that came to you while reading the complete paper.
  • Use arrows, and underlines, circling, strike-through, questions marks, and different colors to express your thoughts.
  • Write some of the questions and thoughts that crossed your mind into the margins.

The textual review:

  • Write a 1-2 pages of review.
  • The review should not shy away from criticising the papers problems.
  • But also remain constructive with suggestions how to improve.
  • The review should refer to concepts which we discussed in lecture.
  • Use section and line numbers to pinpoint your feedback to specific parts of the paper.

The code review:

  • Are the instructions sufficient to get the code set up and run?
  • Does the code do what the authors claims it should do?
  • Do the paper and the code fit together topicwise?
  • Does the paper tell the reader in which file and lines they will find the code snippets that is discussed?

We will send you a review template with specific details.

See also:

Giving Scientific Talks

With this seminar, we want to introduce you to core techniques of scientific work; each participant is thus required to give a talk about the topic chosen. The talks will be given during a Blockseminar.

Each member of the group should speak for an equal amount of time in the presentation. Please practice your talk several times; in particular, make sure that you do not miss the time limit by much, i.e., by at most 10%; this mimics the strict time limits of real-world conferences and workshops. Consequently, if a talk is significantly shorter or longer, then this fact will have a (negative) impact on the presenters’ grade.

Some general advice on talks:

  • The main goal should be to make the talk interesting.
    • Feel free to leave out parts of your work if you feel it does not fit the format.
    • Feel free to add things not part of the paper if it helps the talk.
    • Use illustrations to your advantage.
  • Consider that most of the audience are other students, that have no clue about your topic. Focus on the motivation of the work you present: What is the setting? What are the interesting challenges? What properties are desirable by any solution? After the solution is presented, what are the impacts on the field?
  • A generally rough guideline on talks is that they should be 40% motivation 40% technical contents, and 20% conclusion, and outlook. You don’t have to stick to that precisely, but keep it in mind.
  • Our talks are short, you don’t need a table of contents.
  • Also see: How to give a good research talk by Simon L Peyton Jones, John Hughes, and John Launchbury.

Grading

Although the grade for the paper is given to the whole group, the final grade between members of a group may differ due to the individual grading on the talk and reviews.

  • 50% submission (paper + code)
    • the code should fit to the paper, and the paper should fit to the code
    • the writing should discuss programming language research
    • use lstinline and lstlistings, syntax highlighting, discuss code by line numbers and directly put variable names and program parts inline in the text.
    • every page should contain, discuss and explain code (or mathematical symbols).
    • generic, bland writing (weird stylistic sentences (“not only, but even”), repeated sentences, bullet points) is heavily marked down.
  • 20% peer review
    • annotated review
    • textual review
    • code review
  • 30% presentation
    • quality/originality/presentation
    • knowledge/depth
    • delivery