Lindsey Kuper

This spring, I taught our undergrad distributed systems course here at UC Santa Cruz for the first time! It was a blast, and one of the most fun things about it was reading the zines about distributed systems that my students made.

Eight of the zines made by my students.
Eight of the zines made by my students.

I’d been thinking about incorporating a zine-making assignment into a course like this for years, ever since getting a glimpse of the zines that Cynthia Taylor’s students made for her operating systems courses back in 2015. When I saw the beautiful sketchnotes that Romeo Jung made for my colleague Peter Alvaro’s version of this course last fall, I was even more excited to give students an outlet for creative expression through zines. So I jumped at the chance to do it once I was teaching the course myself.

The zine assignment went well enough that I’m writing this post about it in the hope that it might be useful for other folks teaching CS who want to try something similar in their own courses, and maybe inspire more people to try making their own zines on CS topics.

Introducing my class to zines

On the first day of lecture, I told students that there would be an optional creative project that would be announced a few weeks later. I didn’t say anything else about it then, because I wanted us to have a chance to dig into the course material first (so that, by the time we did start talking about zines, students might already have some ideas about what their zine could be about).

The easiest way to explain to students what I meant by “zine” was to give them an example, so for the day I announced the zine assignment, I got copies of Julia Evans’s wonderful strace zine printed up and handed them out to everyone in class. (Although printing the zines was easy for our campus copy center, they didn’t have the necessary equipment to fold them in half, so I ended up manually folding the zines myself instead of eating lunch that day.)

Although Julia has lots of other zines – and she’s far from the only person out there making computery zines (check out, for instance, the Computery Zine Fest exhibitor list) – I chose this particular one of hers because (a) I felt it nicely captured what I wanted students to be aiming for with this assignment, and (b) it’s free!

The assignment spec

I made this assignment optional, partly because I didn’t really want to force it on people who were uninterested in making zines, and partly because I had eighty-five students and grading that many zines would have been intractable. (I’m sure my awesome course staff would have helped out with grading if I had asked, but grading zines seemed like too weird of a task to delegate to anyone else, at least this first time.)

Here’s the actual assignment specification that I gave out to students. I got in touch with Cynthia Taylor when I was planning this assignment, and she graciously provided a copy of her own zine assignment specification that was the starting point for writing my own.

Instructors, feel free to use and adapt this.

Instructions

A “zine” (short for magazine) is a short, self-published, often hand-drawn/hand-lettered booklet on some topic, usually reproduced by photocopying. For this optional creative project, you will produce a zine on a distributed systems topic. The topic you choose may be something we covered in class, or another topic that interests you and is relevant to the course.

Your zine should explain distributed systems material in a fun, accessible way. Your target audience should be someone who knows computer science, but not necessarily distributed systems – for instance, a CS major who hasn’t taken this class. Your zine should include written explanations, but may include drawings or comics as well.

Depending on how things go, we might ask the class to vote on their favorite zine(s) and print up copies of the winner(s) to hand out to the class or distribute on the course website (with author permission, of course).

This assignment must be done individually. Keep in mind that making a good zine will require many hours of work. Lindsey’s estimate is that it will take at least 15 hours, potentially much longer. Knowing that, if you still want to make a zine, read on.

Grading

If you choose to submit a zine, it will be worth 10% of your grade for the course, and the midterm and final will be worth 15% and 19% of your grade, respectively. If you don’t submit a zine, the midterm and final will be worth 20% and 24% of your grade, respectively.

Submitted zines will be graded as follows:

  • 60% of the grade is based on content: did you choose a topic appropriate to the course? Do you discuss your topic in a reasonable amount of technical depth? Do you incorporate both a theoretical and a real-world perspective? Are concepts clearly defined and explained with thoughtful examples?

  • 30% of the grade is based on presentation: are you providing a unique perspective or telling an interesting story, perhaps with some sort of ongoing metaphor or analogy? Is your zine accessible to a CS audience and fun to read? Is your zine legible and free of spelling errors and other presentational blunders? Do you meet the below formatting specifications? (Note: drawings are nice, but you will not be graded on your drawing skills. Stick figures are just fine.)

  • 10% of the grade is based on references/citations/sources: do you appropriately cite all of the sources you used? Does your zine have pointers to useful resources where readers can learn more? At least one page of your zine should be devoted to a list of references/citations/sources; Lindsey suggests using the inside back cover for this.

Formatting specifications

  • Your zine should consist of at least four pages of standard US letter-size 8.5” x 11” paper, printed on both sides, and folded in half to form a booklet. This will result in a front cover, a back cover, an inside front cover, an inside back cover, and 12 internal pages. We recommend designing your zine with enough of a margin around the edge of each page to tolerate some degree of error in printing and folding.

  • You may add additional internal pages if you need more space, although in order for the format to work, the number of internal pages has to be a multiple of four – so if you want more than 12 pages, for example, you need to go up to 16. (Keep in mind that longer is not necessarily better.)

Submission

  • Your zine is due by 11:59:59pm on Friday, May 31. You may submit your zine either physically or electronically.
    • To submit in physical format, bring it to class or office hours that day, or otherwise make sure it is physically in Lindsey’s hands before midnight.
    • To submit in electronic format, email lkuper@ucsc.edu with an attached PDF that is laid out to print in “booklet” format. This means that the front cover should be on the same page as the back cover, the inside front cover should be on the same page as the inside back cover, the first internal page on the same page as the last internal page, and so on. (See the print version of Julia Evans’s strace zine for an example: https://jvns.ca/strace-zine-v3-print.pdf)

Resources

Looking for examples of zines about computing topics? Here are a few links:

This is just the beginning – you’ll find a lot more out there if you look.

Acknowledgments

This assignment is inspired by Cynthia Taylor’s zine assignments for her operating systems courses at Oberlin College and UIC (see photos: https://twitter.com/pinkhairedcyn/status/599310967047061504, https://twitter.com/pinkhairedcyn/status/674647900434137090).

Students had a little over a month between the day the assignment was announced and the day it was due. I didn’t say anything in the spec about accepting late assignments; in the end, one or two zines ended up being submitted a couple of hours late, which was okay with me.

After the spec came out, a few students came to me to ask whether such-and-such topic was “still available”, which surprised me a bit since I hadn’t specified that topics had to be unique and wasn’t keeping a list of who was doing what topic. But students seemed to care about not having their topic be too similar to anyone else’s. For the record, overlap in topics didn’t bother me. (After all, there’s more than one zine’s worth of stuff to say about, for instance, replication or consensus.) I did look for each zine to offer a unique perspective on its chosen topic, though.

In addition to sending me a PDF or handing me a physical copy, I asked everyone who submitted a zine to fill out a short Google form with their name, the title of their zine, and whether or not they would be willing to share their zine. The options were “share publicly on the course website”, “share only with the rest of the class”, and “don’t share”.

The results

In the end, sixteen students submitted zines, and out of those, eight gave me permission to share their zines publicly on the course website:

The PDFs are formatted to be ready to fold into a booklet when printed double-sided. (The first four should be printed double-sided with short edge binding, and the last four should be printed double-sided with long edge binding.)

There were eight more that I don’t have permission to share, and maybe their authors will decide to share them eventually!

How I graded the zines

I wanted this assignment to be truly optional, so instead of having it be extra credit, I chose to have it replace another part of the course grade: For students who made a zine, exams were worth 34% of their grade and the zine was worth 10%, while for those who didn’t make a zine, exams were worth 44% of their grade. (The rest of the course grade was made up of the course project (46%) and participation (10%).)

As promised in the assignment spec, I graded the zines based 60% on content, 30% on presentation, and 10% on citations. To do that, I came up with the following rubric.

thing points
Content: Topic appropriate for the course 7
Content: Technical depth 7
Content: Both theoretical and real-world perspectives 8
Content: Concepts clearly defined and explained with thoughtful examples 8
Presentation: Accessible to a CS audience and fun to read 5
Presentation: Legible and free of spelling errors and presentational blunders 5
Presentation: Meets formatting specifications 5
Citations/resources: Appropriately cites all sources used 4
Citations/resources: Has pointers to useful resources where readers can learn more 1
total 50

For each zine I graded, I also took the time to write a paragraph or two of comments on what I liked about it and what I thought could be improved, and shared those comments with the author. I probably couldn’t have managed this if I had many more than sixteen zines to grade, but it was doable this time.

Things I want to do differently next time

Some of the zines had technical mistakes or misinformation, and I didn’t realize until I started seeing these mistakes that there wasn’t anything in my rubric about technical accuracy! Next time, I’ll probably allocate some points specifically for that.

Formatting and scanning gave some people a lot of trouble. I gave students a choice of either sending me a PDF copy (which had to be in “booklet layout”, so the pages would be in the correct order and orientaion when printed and folded) or handing in a physical copy. My hope was that giving people the option of handing in a physical copy would help prevent PDF formatting snafus. Even so, I had some people turn in incorrectly formatted PDFs. There were also some PDFs turned in that were really poor-quality scans. I didn’t want to take off points for these sorts of issues, since they could have been more about lack of access to resources than anything else, so when I got a badly formatted or scanned PDF, I just gave the student in question a second chance to hand in a physical copy (which I then scanned myself), or a PDF with in-order pages (which I then ran through a free Mac app I found that converts to booklet layout; you could probably also use ImageMagick and a short shell script). All this took time, and it wouldn’t have been feasible had I needed to do it for more than a few zines. In the future, I’m not sure what I’ll do. Maybe it would help to give students a template PDF with numbered pages.

It seems that some students could have used some more guidance on how to properly cite sources. For example, some zines would use big chunks of text from a cited source without quoting the text (possibly changing a word here and there), and call it good because they included a citation. In the future, I’ll try to emphasize that when you’re using someone else’s words, it’s not enough to just have a citation; you also need to actually quote the words you’re using. I care about this enough that it should probably be a bigger part of the grade next time.

One odd thing I noticed was that some zines would only provide the hostname of a website they were citing instead of the full path. For instance, if they used material from “cs.foo.edu/~bar/courses/distributed-systems/2017/lecture-notes.pdf”, they’d just cite, say, “cs.foo.edu”. In fact, more than one of the zines just cited “composition.al”, which was kind of confusing because I have no idea whether the person was citing one of my blog posts (and if so, which one), our course website, a different course website, the abstract concept of “Lindsey Kuper”, or what.

Some of the zines didn’t hold up all that well to printing or scanning – for instance, sometimes light handwriting became hard to make out, or sometimes stuff that was too close to the edge of a page got cut off. It was a shame when this happened for a zine that was otherwise beautifully done. I did say in the assignment spec to make margins wide enough “to tolerate some degree of error in printing and folding”, but a student suggested that in the future, I should explicitly say “half-inch margins on every page” or something like that. Maybe “use black ink” should also be in there.

Finally, I had said in the assignment spec that I might let students vote on their favorite zines, but in the end, I opted not to do this, because I didn’t want a popularity contest, and I didn’t want it to appear as though the outcome of the vote would be a factor in grading (which it wouldn’t have been, anyway). Instead, I just advertised the zines to the students and encouraged them to take a look. Nobody complained to me that they didn’t get to vote on zines. I have no idea how many people actually ended up looking at each others’ zines, but I hope a few of them did!

Things that went well

With zine grades replacing a chunk of exam grades, it turned out that 75% of the students who submitted a zine had an improved overall grade as a result! In some of those cases, the grade bump was enough to make a difference in the student’s final letter grade (e.g., a B+ instead of a B). For the 25% of zine submitters who didn’t improve their grade by doing a zine, it wasn’t necessarily that their zine grade was low; in some cases, it was that their exam grade was already high enough that even a high zine grade didn’t help them.

I didn’t want anyone to actually end up with a worse grade as a result of having made a zine, so for everyone who made a zine, I calcuated their grade both with and without the zine grade and then gave the maximum of the two grades. I think this worked out well; at least, nobody complained about that aspect of grading. (I suppose that some students may have still hurt their grade by doing a zine, in the sense that the time they spent on the zine may have taken away from time better spent studying or working on the course project, but that was their choice.)

Enough about grades, though. For me, the most fun part of this project was getting to see a side of students’ personalities that I probably wouldn’t have gotten to see otherwise. It was cool to see all the different directions that people chose to go in with their zines, and some of the students actually thanked me for giving them an opportunity for creative expression in a CS course, which was really gratifying. I was especially impressed by how funny a lot of the zines were! I think humor is a vital part of education (and life), and a skill worth cultivating, and a lot of the zines delivered on humor.

All the zines that were submitted were on-topic for a distributed systems course, but while some of them stuck to material that was covered in lecture, others went into a fair amout of technical depth on things that we hadn’t had time to fit into the course. It was helpful to get a sense of what kinds of things students were interested in that I didn’t cover in class; maybe I ought to make room for those topics in the future.

I’m especially glad that students let me make some of the zines public, because that means I can use them to show off the course to prospective students. (Our undergrad courses are already so oversubscribed that maybe advertising is ill advised, but.) I also think some of the zines might make useful study guides for students taking the class in the future, like when I teach it again next spring!

Comments