Course shifts: feature proposal and discussion

Owned by Boris Zimka
Last updated: Dec 19, 2017

This page was created according to the Ned Batchelder advice to contact OpenEdx products: https://groups.google.com/d/msg/edx-code/MyM5sV9HQxM/YjdmPFtNBQAJ

We (https://openedu.ru) have implemented a new feature for OpenEdX, that allows to shift start and due dates in course. Code and short description are available here.

The feature is raw, but it has been already tested at one of our minor OpenEdx instances with real learners. We would like to contribute to OpenEdx and therefore we would like to discuss it with OpenEdx team.

Background

Currently there are two main types of course scheduling in edx: instructor-pacing and self-pacing. With the first one it is easier to support students and to motivate them for course staff, the second one can be more flexible and (in some cases) more comfortable for students.

Both of these type are not very convenient for course authors when the course is rather short and intended to be launched quite often, but can't be run as a self-paced for any reason (e.g. it's part of program from several courses). It is hard for staff to maintain multiple ongoing course runs with distance in several weeks (e.g. in case of wrong task or new content addition same changes should be applied for every run).

When courses are launched often, it is also possible that there are not so many students in each run and discussions are quite unpopulated.

Another drawback is that it could be hard for student to catch the due dates and to accomplish course if he missed several weeks.

Abstract

Feature adds new entity called "course shift". Each student can be assigned to only one shift for each course (or not assigned to any). Shift has a "shift start date", and course effectively starts at "shift start date" instead of the "course start date" for every student in given shift. This means that for every problem due date is shifted by ["shift start date" - "course start date"] days. Students are still at the same course run, so there are next consequences: 

  • student preserves progress after changing the shift

  • students from different shifts share discussions

  • students can be at the same cohort but at different shifts, and vice versa

Shifts are setup by course staff. Student can be assigned to shift at the enrollment, can be transferred by instructor or student can switch his shift himself (forward only).

Specification

In sense of student assignment and division, CouseShifts are based on CourseUserGroups and their design follows the one for Cohorts. Currently there are two modes of shift management, the manual mode and the automatic mode. In automatic mode shifts are generated periodically according to the settings. In manual one each shift should be created by staff explicitly.

Due and start date shifting are implemented via FieldOverrideProvider, similar to the INDIVIDUAL_DUE_DATE feature: when the field is accessed, user is checked to be in CourseShiftGroup and dates are changed accordingly if it is needed.

Installation

Feature was developed for "ficus.1" release, also it was tested on "dogwood" release. Feature installation is described here.

After installation and enabling feature for course the  new tab appears in the instructor dashboard, where shifts can be configured. Also there is small dropdown with shifts names at the enrollment view near the "enroll" button when student is enrolling on course.

Currently students can't change their shift themselves.

Tests for feature were run by command after adding it to INSTALLED_APPS in test.py:

paver test_system -s lms -t <course_shifts_addr>/course_shifts/tests/test_shifts.py --settings=test

Feedback and refactoring

While there are definitely a lot of things that can and should be improved, refactored and so on, the weakest part (as we see it) is UI.

Currently instructors setup and work on shifts at the instructor dashboard. This approach forces to change instructor_dashboard code in edx-platform, what we would like to avoid.

Also it is not quite clear how and where interface allowing student to change his shift should be placed.