During my master studies in computer science at Radboud University, I followed three research seminar courses: on software science, on mathematical foundations of computer science and on privacy. Normally, students would only do the one seminar course that had to do with their specialisation (i.e. software science, formal methods or computer security), but I chose to do all three as part of my free elective courses.

I like the format of seminar courses since students generally get a lot of freedom and responsibility during those courses. I also find that they are excellent practice for being a PhD student: I got to know the research staff better, practiced various research skills and got a more realistic view of what it means to do research (as opposed to doing scoped, guaranteed feasible homework).

All three seminars had different formats, and now that I am a PhD student (and occassionally help out with teaching at the University of Twente), it is helpful to have an overview of the potential formats for a seminar course, either for me or as inspiration for my colleagues.

I have tried to describe a lecture plan for each format. All courses are semester courses, i.e. two quarters of about 8 weeks of teaching.

If you get (too) many students for a course, you can do two things: (1) set a maximum number of students that can enroll (not always possible because of institutional policies) or (2) adjust the group size, and then adjust the workload by changing the lecture length and paper length where neccesary.

If you used one of these formats, I’d love to hear your experiences. If you have ideas for improvements, let me know in the comments. I hope these formats can be of some benefit to university teaching staff out there. :)

Based on the course MFOCS research seminar (2014), half-year course, 6 EC

This course was given by a group of ~5 lecturers with the same research field. In the first half of the course, each lecturer would give a lecture about their specialisation, and describe it in the context of the larger research field. This is the capita selecta part of the course. In addition to these lectures, students would form groups of two and do a research project with one of the lecturers during the course. The research project was new, based on some ideas by the lecturer and not well-defined when we started. This is risky but rewarding, and can give students a realistic view on what it entails to do research. Good prep for students thinking of doing a PhD. For me and my project partner lead to our first published research paper.

Student groups would present twice: two weeks after starting (15 minute presentations), and near the end of the course (30+ minute presentations).

```
Lecture format (example):
1 introduction lecture
lecturers present their topics
deadline: students choose groups and supervisor (1 group per lecturer)
2 lecturer 1
3 lecturer 2
4 lecturer 3
5 lecturer 4
6 lecturer 5
7
8
1 student groups present their research plans (short presentations)
2
3
4
5 student groups present their findings (long presentations)
6 student groups present their findings (long presentations)
7
8 deadline research project report
```

Based on the course Privacy seminar (2015), half-year course, 6 EC

This course was given by two lecturers, who both had a different perspective on the course topic (privacy): one computer scientist, and one lawyer. They both gave a lecture at the start of the course, in which they gave an overview of the course topic from their respective specialisations. They took care to point the students towards useful resources (field-specific terminology, literature) needed for the project work of this course.

At the end of the first lecture, students make groups of 2 and choose a topic from a list provided by the lecturers. Based on this topic, they prepare a full lecture (2x 45 minutes) in which they teach their fellow students about this subtopic, as if they were a lecturer themselves. Each group also prepares a 10-page research report in which they summarize their findings and describe at least two different technologies that try to solve a particular problem in the area of their subtopic. This research report is not about doing original research, but writing a small survey of a particular area and summarising the most important problems and developments.

The student lectures can start directly after the first two introductory lectures given by the teachers. As a teacher, you can decide to give your students a bit more time to prepare before the first student lecture. You could skip a few lectures, or invite industry speakers to talk about the course topic. Do a “peer-review” in class after each student lecture. Ask students in the classroom to give compliments and points of improvements for the lecturing students.

The report is due at the end of the course, but students would get a change to meet with the teachers to get feedback on the ‘skeleton’ (structure) of their report before handing it in. Additional meetings with one of teachers were possible in case of questions/problems, on an on-demand basis.

```
Lecture format (example):
1 introduction lecture
lecturers present their specialisation
deadline: students choose groups and topic
2 introduction lecture, lecturers present their specialisation
3 (guest lecture)
4 (guest lecture)
5
6
7 student lecture 1
8 student lecture 2
1 student lecture 3
2 student lecture 4
3 student lecture 5
4 student lecture 6
5 student lecture 7 + deadline: research report skeleton
6 student lecture 8
7
8 deadline: research project report
```

Based on the course Software Science research seminar, 6 EC, half-year course

This course focuses on reading (influential) research papers, explaining them to others, and writing constructive reviews. Students write two long-form reviews of two influential research papers: one paper that is a ‘classic’ in a particular field, and one more modern paper (for example, a publication that has recently won a best paper award at a relevant conference). The lecturer provides a list of these publications at the beginning of the course, and students can choose which papers they would like to read. The lecturer then makes a one-to-one mapping from students to papers.

Student reviews consist of: a description of the problem that the author try to solve, how this problem is situated in the research field, the solutions that the authors propose, what kind of evidence they give for their solution, and an analysis of the writing style and argumentation. Reviews should be 4-6 pages. Besides the long-form reviews, students also read one of the two presented papers of that week, and write a short review (summary + analysis of at most 1 page) for that paper. In the second part of the course, students were asked to write a constructive “review” one of the student reviews from the first half of the course.

During the lectures of this course, students take turns in explaining “their” paper to their fellow students in a half-lecture of 45 minutes. Students in the classroom are encouraged to ask questions and give feedback.

```
Lecture format (example):
0 lecturer provides publication list, students send in their preferences
1 student presentation classical paper 1 + 2
2 student presentation classical paper 3 + 4
3 student presentation classical paper 5 + 6
4 student presentation classical paper 7 + 8
5 student presentation classical paper 9 + 10
6 student presentation classical paper 11 + 12
7
8 deadlines: first long-form review,
various short reviews of classical papers
1 student presentation new paper 1 + 2
2 student presentation new paper 3 + 4
3 student presentation new paper 5 + 6
4 student presentation new paper 7 + 8
5 student presentation new paper 9 + 10
6 student presentation new paper 11 + 12
7
8 deadlines: second long-form review,
various short reviews of new papers and/or review of student review
```

Judith van Stegeren is a Dutch computer scientist. She is working as PhD candidate at the University of Twente, where she researches natural language generation for the video games industry. She occassionaly works as a consultant in data engineering for textual data.