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:

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:

Other sharing concerns:

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

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.

Browser not supported