palvaro/CMPS232-Fall16: a reading seminar graded mostly on participation

The entire repository is a README and a reading list

The top level of this repository contains two files: the README that holds the syllabus, and a readings file. There is no source code, no build configuration, no licence file and no recorded programming language, which is the correct shape for what it is. One detail is easy to miss and worth noticing before you copy the structure: the readings link in the syllabus table points at a different repository, one named for a different term, and it is annotated as volatile and subject to significant change. So the reading list is not versioned alongside the syllabus that assigns it, and a syllabus copied from here would be assigning homework from a file it does not contain.

Impossibility results are the frame, not the syllabus

The theoretical half of the course description is not background reading, it is the argument for the whole course. A great deal of theoretical work in distributed systems establishes impossibility results, and the syllabus names the famous ones: the FLP result, the CAP theorem, the two generals problem, and the impossibility of establishing common knowledge through protocol. The purpose given for teaching them is precise. They say what cannot be achieved, or more usefully, they say which properties must be traded away for the properties you require when designing or using large-scale systems. The question that follows is what can be achieved, and the answer offered is that the history of applied work is largely a history of infrastructures, storage systems and programming models, that manage the domain's fundamental complexity through abstractions.

Every programmer now writes distributed code

The premise of the course is a claim about the state of the industry rather than about systems research. Distributed systems are presented as difficult because of fundamental uncertainty arising from asynchronous communication and partial failure, and then as ubiquitous, since nearly all non-trivial systems are now physically distributed. From those two premises comes the conclusion in the syllabus: it is no longer possible to relegate responsibility for managing distributed complexity to a group of expert library or infrastructure writers, so all programmers must now be distributed programmers. The document is careful about how it frames that, saying it is both a crisis and an opportunity, and the topic list follows from it by covering storage, consensus, replication, fault tolerance, programming models, distributed languages and program analysis, and seminal theoretical results.

Two papers a session, one page each

The reading workload is specified tightly enough to plan a term around. This is a research seminar, so the sessions are reading and discussion of conference papers, one or two per session and typically two. For each paper the student provides a brief summary of about a page, and the syllabus then lists five questions the summary should answer, phrased as some or all of the following. What problem does the paper solve, and is it important. How does it solve the problem. What alternative approaches exist, and are they adequately discussed in the reading. How does the work relate to other research, whether covered in this course or not. And what specific research questions the paper raises for the reader.

Slides are optional and the whiteboard is endorsed

Presentation expectations are deliberately loose in form and firm in quantity. Every student is expected to present at least one research paper to the class, and ideally two. The format is open: students are not required to prepare slides, though the syllabus notes that doing so may help organise the subject matter. If you do use slides, they must be original, created by you, and any external material such as figures must be properly attributed. If you choose not to present slides, the instruction is to use the whiteboard well. That pairing says something about what the course is measuring: whether you can hold an argument about a paper in front of a room, rather than whether you can produce a deck.

Projects are graded by novelty or by completeness

The final project comes in two kinds with different criteria. A research project presents novel work that could eventually lead to a conference or workshop publication, and the syllabus strongly encourages that kind, on the grounds that research is what the course is for. Because systems research is challenging and quarters are short, teams of up to three are allowed, the number of contributors is considered when projects are graded, and a team of three can and should take on a substantially more ambitious problem than a pair or a single author. A survey paper instead attempts a complete picture of work in a narrow area, and unlike a research paper it is judged on completeness rather than novelty, may only have one author, and should not cover material already covered in class.

Reusing a paper from another class is the line

There is a short rules section about reuse that is stricter than the rest of the document. Re-submitting a paper already submitted in any form to a class from a previous semester is not allowed. Submitting a paper concurrently to another class is allowed, but only with pre-approval from the instructor, and in that case, as with group papers, the work is expected to be especially strong. The phrasing matters for anyone adapting this: the prohibition is on prior submission in any form, not on prior publication, and the exception for a concurrent class submission is a permission to seek rather than a permission to assume. Everything else about the project rules, including the team size limits and the one-author rule for surveys, is stated as a requirement rather than a default.

Participation is a fifth of the grade and citing is not optional

The grading table is four rows and blunt about their relative weight: paper summaries at twenty percent, participation at twenty percent, presentations at twenty percent, and the project at forty percent. Final projects are required to pass the course, and the document points out that participation carrying twenty percent should give an idea of the importance of attendance. The academic honesty section is the longest passage in the file. Collaboration is encouraged, with discussion of readings and project ideas, but you must reveal in your summaries which students you discussed papers with, and failure to do so results in formal disciplinary proceedings. Plagiarism is stated as unacceptable and not tolerated, and the argument given is about attribution rather than punishment: researchers stand on the shoulders of giants, building on existing work is the norm, proper attribution is essential, and when in doubt you should cite.

Editorial conclusion

Use this repository as a template rather than as a course to take. The grading split, the five questions a summary should answer, the two kinds of final project and the reuse rules are all reusable as written, and the honesty section is unusually explicit about what collaboration requires. Two things to change if you adapt it. The reading list does not live in this repository at all, since the link points at a different semester's file and is marked volatile, so the topic list and the readings can drift apart. And the logistics block is specific to one room and one teaching assistant, with a closing tag left in the schedule text.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases