Logistics of Teaching Large Courses: Part 3. designing your course calendar and policiesBefore the term starts, you need to set up the syllabus for your course, which contains two main parts: calendar and policies. Course CalendarThe calendar dictates the scope, pace, and rhythm of your course, so I would set that up first. Everyone's course is different, but we're all constrained by the calendar; nobody can bend time! Start by marking out the weeks on a draft calendar and noting when holidays occur this term. Even if you're re-teaching the same course again, the calendar will be slightly different this time since holidays fall on different days, you may need to travel on some days, and there might be spontaneous opportunities for cool guest lectures from out-of-town visitors on other days, which all require re-working the calendar every time you teach. Flow: The main guiding principle in setting up a course calendar is to have a rhythmic flow of content each week going from, say:
If you space these events too far apart on the calendar, then your course's pace will feel sluggish; but if you cram them too close together, then it will feel too rushed. If you're afraid you might be trying to cram too much material into your course, you probably are! Like everything else (e.g., writing, video editing), if you cut out 30% of your material, it will probably be more compelling. Setting Due Dates: Plan for more chaos during the day before each assignment is due. In a large course, some student emergency will inevitably come up before each deadline, last-minute mistakes may be found in your assignment, or the submission website might crash due to heavy traffic. Thus, if you set due dates on Sundays or Mondays, do you really want to be dealing with these logistical issues on your Sundays? I like to set Thursday night deadlines so that nobody needs to scramble over the weekend. Exams: If you're planning to have exams, space them out on your calendar as you see fit. Then write down exactly which lectures are going to be covered by each exam, so that students can know what they need to study (e.g., “Exam 1: covers lecture materials from Sep 1 to Oct 10”). In each exam's calendar entry, also link to the general exam format on your course policy document (e.g., are they open notes? closed notes? bring your own calculator?). If any student asks you, “what's on the exam?” you should be able to simply point them to the calendar entry. Holidays: I'd avoid scheduling exams the day right before or after a holiday or other long weekend, since many students may still be traveling around then. If you schedule on those days, you'll get lots of last-minute requests for taking make-up exams, which is a logistical mess. Lecture attendance is also low during those days, so I sometimes use those slots to prototype some optional experimental lectures (such as my HCI/Design Jobs talk), hold informal Q&A sessions, or just cancel class. Cementing: Once you've set your assignment due dates and exam dates, don't change them later since students may make travel plans or schedule other extracurricular activities around those dates. It's OK to make changes to lecture or assignment contents within reason, but key dates should be cemented before the term starts. Final note: you might think that moving an assignment due date to later (i.e., giving the entire class an extension) may be generous, but many students will (rightfully!) feel resentful since they worked so hard to meet the original deadline, only to see it moved back last-minute. It just feels unfair. Course PoliciesThink of your course policy document as a binding contract that you make with your students. My colleague Leo Porter says it best: “Have clearly defined policies – apply uniformly.” Again, this goes back to fairness. Your course policies should clearly and unambiguously spell out what's expected from both students and staff. It should be the definitive source of answers for student questions. If your policies are well-designed, then you should be able to answer most questions by directly citing this document and linking to the relevant section. This makes everything as transparent and fair as possible, and also saves you time because you don't need to craft a custom response for each student's question. Thinking like a lawyer: Is there ambiguous wording in any part of your policy where students can argue for interpretations that you didn't originally intend? Given enough students in a large course, somebody will always be able to find surprising loopholes in your policies, which you should patch up for next time. An ironclad but fair course policy document is impossible to write the first time around, so plan to iterate over many years to continuously improve it. Don't worry if this document seems to be growing longer and longer over time; students will appreciate your attention to detail as long as they perceive it as being fair. Cementing: Like your course calendar, you shouldn't change policies mid-way through the term since that's unfair to students. If you need to add clarifications, you can create an FAQ (Frequently Asked Questions) section at the end and make updates there. Then the next time you teach, integrate those FAQ entries into a new version of your policy document. Granting exceptions: Expect the unexpected. With hundreds of students, extenuating circumstances are inevitable, so you need to figure out what your philosophy is for granting exceptions to your written course policies. If you're too rigid, then you may be disadvantaging certain students who truly have well-justified needs; but if you're too loose in granting exceptions, then that may also be unfair to other students (who may not know to assertively ask for exceptions). This balance can be tricky to get right. Again, I try to be guided by maximizing fairness. One idea here that I like is the concept of slack days or free points: every student gets a few free days to turn in their assignments late, free absences (if attendance counts for grades), dropped grades for lowest-scoring assignments, or other freebies. There's no need to ask for permission or to have a justified reason. This simple mechanism elegantly covers a wide range of student emergencies without requiring you to decide on individual exceptions. Note that if you go down this path, you need to make it extremely clear that these are the only exception-granting mechanisms in your course; otherwise some students will use up all of their slack days and then ask you for additional ones. One issue with slack days/points is that your staff needs to keep track of when each student has used those throughout the term, which may be hard to scale to hundreds of students. (But if you grant individual exceptions, you still need to keep track of them!) Next part: Logistics of Teaching Large Courses: Part 4. dealing with start-of-term chaosAppendix: Example Course Policy ComponentsHere are some typical components of a course policy document:
Example Staff Contact Protocol (from my HCI course)
Example Exam Policy (from my HCI course)There is no final exam, but there are two midterm exams held in lecture (Exam 1 and Exam 2). The exams are closed-note; you may not use any outside resources. What will exams cover? Anything covered in lecture, code labs, or the online videos linked from either is fair game for the exams. We often cover theory from lecture (e.g. heuristic evaluation, study design), and coding techniques from lab (e.g. version control, jQuery selectors, t-tests). Regarding the code labs: you'll have to know how to read code on the exam, but you do not need to write code yourself from scratch. We won't grill you about some tiny nitpicky code construct that appears only on the corner of one slide in tiny font; the coding concepts that you will be tested on will often appear in multiple slides. If you are working your way through the labs (not simply reading what's on the slides), then you should have a good understanding of the required material for exams. There are no practice exams posted; the slides and videos on the course website should be all that you need to study. You cannot take exams early since they will not be ready until the day of the exam (they usually cover content up to the prior day's lecture). Example Team Formation Policy (from my HCI course)All work in this course will be done and submitted in teams of 3 or 4. It is your responsibility to form teams; the staff will help out, but we will not automatically assign anyone to your team without your permission. (Exception: if you have less than 3 people on your team, then we will assign additional people to your team.) Due to staff resource limits, we cannot grade projects done by teams of 1 or 2; teams need to have 3 or 4 members. If you cannot find a team, then you will not have grades for the project milestones, so you will not be able to pass the course. There will be no grading extensions for students who find teams too late. Once teams have been formed and submitted in Milestone 1, they must remain fixed for the rest of the quarter. You cannot switch teams mid-way throughout the quarter since it is not fair for your teammates who are depending on your commitment to the project. The only exception is if team members drop the course; you are free to drop the course at any time if you like. But if dropping causes a team to have less than 3 remaining members, then we may assign additional students to that team. [Note: I highly suggest having students finalize their team formations after the deadline to add courses (usually after weeks 2 or 3) so that enrollments have stabilized by the time teams form. Otherwise it can be a pain to reshuffle teams if some students try to join teams at the beginning but then can't get into the course from the waitlist, so they need to drop the course.] Example No-Late Policy (from my HCI course)No late assignments will be accepted. This is because you will present your work in Friday's section every week, so you need to be prepared to participate. Another reason for our no-late-assignments policy: Any of your team members can make a submission, so in case one or more members are out sick or are overwhelmed at the moment, the remaining members can be there to make up the work for a given week and submit the assignment. We give you enough advanced notice on due dates to plan around when some of you will be busy. [Note: No-late may be too strict for assignments done individually rather than in teams. Slack days may work better there.] Example late make-up exam policy (from my HCI course)Here's my policy if students ask to take an exam late: Exam dates are posted at the beginning of the term, so if you want to enroll in this course you need to be sure you can make it to exams. My standard policy for late exams it to let you take it late, but you'll get 2/3 credit for being late (2/3 of the points you earn, rounding up to the nearest whole number). The reason why I have this policy is that if there are no consequences for late taking of exams, then everyone who isn't properly prepared will just ask for an extension with no consequences. That will not be fair to students who study and take it at the assigned time. Note that exams comprise only a small fraction of the total grade for this course, so I think 2/3 is very fair. However, it might be too harsh if exams count for more of the course grade, so you can try something like 80% or 90% credit. (Sometimes students will have conflicting final exam times, in which case they should be able to take a make-up without point deductions.) |