What would it take to practically implement such a flexible extension policy?
- It must be possible for late work to be graded “off schedule” without requiring excessive staff effort. In many of our large courses, this problem is solved by autograders.
- The management and tracking of extension requests, including (ideally) automatically adjusting submit deadlines in the LMS or other submission mechanism, must be highly automated to avoid requiring staff effort.
The Extensions Pipeline (dubbed Flextensions) is a lightweight framework designed to support the second goal—tracking, approving, and managing extension requests in medium and large classes (e.g. N > 50). It’s optimized for courses in the EECS department at UC Berkeley, but is extensible to other departments and universities.
At a high level, this pipeline consists of:
- A Google Form that students submit extension requests to.
- A Google Sheet that collects student extension requests and tracks all extension requests in a master roster.
- A Google Cloud Function that contains core business logic that:
- Receives form data through a simple Google Apps Script trigger.
- Process form data in combination with a student’s “record” (which includes DSP status and prior extension requests) to enter either an auto-approval or manual-approval flow.
- Sends updates to staff through a Slack Webhook, enabling simple internal discussion of student cases through Slack threads.
- Sends updates to students through the CS 162 Mailserver via CS 61A’s RPC Interface.
- Optionally publishes assignment extensions to one or more Gradescope assignments.
Traditionally, courses deal with two types of extensions:
- DSP Extensions, for students with accommodations for assignment extensions
- Non-DSP Extensions, for students facing extenuating or otherwise unforeseen circumstances
Courses traditionally collect extension requests through Google Forms (e.g. ones provided by course managers, like this one) or via email. In order to approve these extensions, however, courses (or course managers) need to:
- Read the student’s request and categorize it into a DSP or Non-DSP extension.
- Look up whether the student has previously requested assignment extensions.
- Either (a) update the student’s requested extensions in a central spreadsheet, or (b) update the student’s requested extension on Gradescope/OKPY/PrairieLearn.
- Send an email to the student containing an “Approved” message, with a new due date.
The traditional flow results in several challenges, including:
High potential for human error. In every manual step, there’s a chance for data entry errors that are capable of propagating downstream; in CS 161/CS 61C, we saw a large number of these that arose at the end of the semester when generating final grade reports.
Communication difficulties. For classes that outsource work to course managers, there are three parties with different views on extension data: what course managers see, what course staff see, and what students see. All communication, by default, needs to be inclusive of all three parties; if even one email is two-way instead of three-way, then information is “lost”.
Delayed processing times. Because of the number of manual steps required here, it can take several days for students to hear back on whether or not their requests were granted, leaving them in a state of stress and uncertainty.
High barriers to requesting extensions. Because there are so many steps in approving each extension, there’s a tendency to write strongly-worded policies discouraging most student extension requests.
The Flextensions Pipeline addresses all of these challenges, significantly reducing course staff workload while simultaneously improving quality-of-life for students.
The GitHub lives on the CS161 platform as well as here (on my private GitHub), that is primarily used for beta testing updates before pushing them to the official platform in the 161 organization repo!