2015.02.13 Personal Online Courses (CCX)

Attendees: Ned, Miki, Andy, Steve Magoun, Cale, Beth, Dave O, Ferdi, Peter Pinch, Brandon, Nimisha

On Hangout: Chris Ewing (Jazkarta), Jim Abrahamson

Today there will be two categories of feedback:

  • (LIST 1) this is MVP, but we need to fix this thing (security). Cover these in depth.
  • (LIST 2) we might do this very differently, here's how I would do it differently. Write these down and move on.

Peter presenting.

POCs were started a long time, ago, with a proposal on the code list.

Implementation given to Jazkarta. Chris Rossi did initial implementation.

Current status:

  • There are two PRs out for review
  • It's running on MIT
  • research paper published in EduCause about the research that preceded this work
    • 28% of MIT MOOCs are educators
    • They have been asking to use the MOOCs in their classrooms, to re-use the content
    • Initial approach: create SPOCs
      • high start-up cost for both sides
      • too much flexibility for teachers to change courses, more than MIT wants
    • Looking for a way to create a small course
      • Students invited by the teacher
      • Teacher can change the dates (this was the biggest effort in making the SPOCs)
        • MIT paces courses faster than teachers want
        • Start dates are of course different.
    • MIT had an extension called Individual Due Dates
      • First thought: use this to change the dates for POCs.
    • Field overrides were designed with Cale
      • This overcame some problems with IDD

Key features:

  • change due dates
  • new role: coach (Khan uses this word)
    • instructor can make someone a coach
    • the coach can create a CCX
  • student management, coach invites students
  • coach needs to see student grades
  • haven't figured out the business side
    • do we monetize this?

Implementation constraints:

  • Role is a limited way to change the presentation of tabs
    • Thread-local is being used to allow behavior, like the CCX tab.
    • The role is being examined explicitly.  Is this OK? Better would be has_access() (LIST 1).

This will run on edx.org

Sharing things between the CCX instance and the "parent" MOOC

  • If a student answers a question in the CCX, have they answered in the MOOC?
    • Can a student be in a CCX, and also in the MOOC?
      • current implementation: if you are in the CCX, you are also in the MOOC.
      • two separate enrollments, in two separate tables
      • this might not be a hard requirement, the implementation could change.
  • Ferdi: if we allow any configuration, we can be flexible later
    • Miki: too much flexibility is not where we want to be.
  • Cale: a student should be enrollable in a MOOC, and in a CCX off that MOOC, but they are separate.
  • Peter: most urgent need: reuse a MOOC with a completely different set of students.


  • Ferdi: CSVs should have a column with CCX info
  • Miki: Insights is based on course ids.  Changing it to aggregate on other info (CCX id) is not easy.
  • Peter: whether analytics should be mixed or not depends on the specific information queried.
  • Dave: everything downstream has to be aware of CCXs in some way.
  • Peter: For MVP, the MOOC would be copied to a new course (new course id), then all CCX would be based off of that copy.


  • content libraries could be a huge help here. (LIST 2)
  • split was created to help make new branches of course. (LIST 2)

Other sharing concerns:

  • How does search work?
  • ORA will assign reviewers from all students in the same course id.
  • What systems have to understand CCX?
  • What path insulates more systems from CCX?
  • Cale: separate course ids will solve more problems. 

Everything in the system is based on course ids.  We have to figure this out. (LIST 1)

  • This includes enrollments

Ferdi: preference is to have CCX be an add-on to edX, rather than an integral feature.

  • Miki: have a very limited trial with an MVP implementation
    • If it's successful, shut it down, and do it right.
    • But if it succeeds, we could be stuck with the MVP data.

Cale: pluggable keys could be a good way to solve this. (LIST 1)

  • (whiteboarding about opaque keys)
    • course_v1: org+course+run
    • course_ccx: org+course+run+ccx
  • still requires spreading CCX knowledge around the code
    • but less than other proposals
  • this makes CCX part of the course/run hierarcy
    • Chris Ewing likes it.
  • CCX should be a view of a course, not a copy of a course.
  • Miki: separation of CMS and LMS
    • state of course at edit time doesn't have to be the state in LMS
      • one course in CMS could be many courses in LMS

Peter: are there implementations of new keys to look at?  Library keys

Field overrides: how would ccx keys interact?

  • They would just key off the course_ccx ids instead of the course id plus the ccx id.

Miki: the key id is not a big deviation from the current implementation, low cost, big benefit.

  • Chris agrees it isn't a big change from today's code.
  • Will this means course lists will be full of CCXs?
    • course listings will not show CCXs
  • course_ccx ids will make it easier to do the common operation of looking up content from ids.
    • Dave O gives a detailed comparison using search about how the course_ccx id will work better than a separated id.