Presentations

We have now had two presentations.  One by Clint on the Linux scheduler and one by Leif on the virtual file system.  These two presentations provide a basis for discussing good style and techniques for such a presentation.  Since Clint and Leif were the first, they got to serve as guinea pigs, but they also get the benefit of the doubt for having volunteered to go first.

Here are some general points to consider.

bulletEach presentation has a topic that comprises more material than can be presented in a standard course-based lecture.  This has a number of ramifications. 
 
  1. The material must somehow be condensed while maintaining continuity and the best possible dissemination of the main ideas, so that the audience comes away with a greater understanding of the topic than they had before.
  2. The material cannot thus be presented in standard classroom lecture style.  Instead, it must be put into a more organized form that leads the talk through all points in timely fashion.
  3. To accomplish 2, a presentation package must be constructed.  PowerPoint is a good basis for a start, because points that are to be covered can be presented in graphical and easy-to-read form.
  4. The presentation should be made available on the web for others to view both before and after the presentation.
     
bulletComments
  1. Recall that Clint had a number of PowerPoint slides that he used to lay out his talk.  This is a good way to do this.  In fact, a presentation like this should be more in the form of a seminar, because that style is more suitable to a topic that condenses a large amount of information into 50 minutes.
  2. Such a PowerPoint (or equivalent) presentation should have a first slide that lays out the talk ("this is where we are going"). 
  3. Then, for our class, there should be a few slides that remind the listeners of the general principles learned in an undergraduate course (e.g., "...remember what scheduling entailed and what the primary scheduling algorithms were...?")
  4. The main set of slides should then be devoted to the meat of the presentation, for example, "this is how my version of Linux does the scheduler."
  5. Finally, there should be summary page that says, "this is what we have done; this is what there wasn't opportunity to cover; and here are the references...are there any questions?

Elaborating on point 4 directly above, this part of the talk should provide the audience with a high level discussion of what the issues are, giving a kind of mental model of the topic.  For example, "in this version of Linux the scheduler looks basically like this..." with diagrams, etc.  This should be followed by a discussion of the issues in detail.  You will need less detail on some things and more on others.  You need to pick out some of the more important or interesting parts for which to go into in detail.  Your slides should have direct links to the code when you show the code (and for this class, you should always get to some code to explain and, where possible, to modify the code to elaborate on a point, as Clint did).  It is up to you to decide what points would be important to go into in the most detail.  The idea is that your listeners should get the best learning experience possible from a 50 minute presentation.

So, again, let's return to our two talks so far.  Clint did a nice job of laying out some slides for his talk that took us where he wanted to go.  There was perhaps a little too much fiddling to get from slides to code and back; direct links might have helped there.

Leif's presentation was the kind that is good for a team working together on code in a situation in which everyone has been looking at related parts of the code and need to get a briefing on how something works. The code was well "tabbed" with links that allowed him to get to the parts he wanted to talk about quite easily.  As noted above, a presentation like this twould have been enhanced with an overview of how in general a virtual file system must work, a general set of pictures and other illustrations about how a virtual file system maps to a real file system, followed by how this actually gets accomplished in the particular version of Linux being looked at.

As mentioned, those who go first get some leeway so that we can more easily specify the parameters.  Those who follow should learn from the strong and weak points of previous talks to do progressively better presentations.