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.

Analytics:

• 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.

Nimisha:

• 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.