What happens when a student is faced with multiple fixed deadlines for formative assessments and cannot meet them all? Our hypothesis is that students may “cut their losses” by simply not turning in some of the work, if the late penalty is so large that they wouldn’t get the points. This results in reduced learning because the student is forgoing practice-with-feedback that they might otherwise have attempted if they thought the “calculus of grading” would justify it, and all because of the presence of a fixed deadline. This scenario works directly against the goals of mastery learning and those of adaptive equity-based grading. Indeed, one of the “checklist items” for implementing equity-based grading is flexible deadlines. That is, requesting an extension should be destigmatized, and within reasonable limits, extensions should be penalty-free, to remove any disincentive for spending more time with practice materials.

What would it take to practically implement such a flexible extension policy?

  1. 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.
  2. 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.
We are in the process of analyzing data from several courses using Flextensions in the past several semesters. We hope to demonstrate that Flextensions have a positive effect on student affect, a non-negative effect on overall student learning as measured by grades on individual assessments and the course overall, and require minimal additional staff time or effort; and that we therefore encourage all courses meeting the above criteria consider adopting the practice.

Traditional Flow

Traditionally, courses deal with two types of extensions:

  1. DSP Extensions, for students with accommodations for assignment extensions
  2. 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!