LabXchange 2018-03-27

  • Clarify limitations of current Modulestore and Content Libraries
    • Scaling issues
    • Coupling xblock runtime with store
    • Black-box ?
  • Planning to reuse
    • XBlocks
    • OLX
  • Agenda
    • Process
    • Flesh out Collections vs Unit vs Sequence
    • Clarify ownership use cases
    • Semantics versus structure - flexibility
  • Process
    • Use OEP? Yes, but timing considerations:
      • Braden: Wants to hash out some of the high level details first.
      • Ned: The more public, the better.
      • OpenCraft doesn't have a contract for LabX yet. Braden doesn't want this public with OpenCraft's name on it before the contract is in place.
      • Gaurav doesn't want it public at this point because they're trying to set up the organization in house first.
        • Ned: Can we take "LabX" out of it and talk about it as an Open edX design discussion?
      • How does adaptive play into this?
        • Nimisha: We need to have requirements, but they don't need to know the details on this yet.
      • We'll check in on Monday about communicating this.
  • Collections vs. Units vs. Sequence
    • Proposed Vision
      • Units
        • "Normal" chunk of content, smallest useful piece.
        • Maps best to a vertical in current edx-platform (could even use the vertical block as implementation)
        • Single XBlock, or a few together (e.g. preamble, video, question).
        • Could have children (implementation detail)
          • For our purposes, smallest chunk.
        • Q: Are Units shareable?
          • A: Yes. Also can see OLX of the Unit via a "view source" type of thing. Not necessarily built into the app.
        • Q: Is UI included in proposal?
          • A: Some UI to import/export, but the focus of this is API.
        • Unit is an addressable piece of content that can be referenced and used in many different places.
      • Collection
        • Simple folder concept, not dynamic/tagged. Item is only in one Collection at a time.
        • Ownership, licensing, permissions can be determined at Collection level.
        • Simple organization scheme to make things easier for content authors.
        • Not planning to build the UI for this.
        • Examples:
          • HarvardX Physics Problem Bank
          • Joe's Course on PCR
          • A bunch of Videos
        • Maps to a Library in the current Studio, but with the ability to hold more different types of content.
        • Historical note: "Collections" term was originally part of the v1 for Content Libraries proposal, that indicated a subset of a Library.
      • Sequences
        • Short, linear pathways of content.
        • LabX doesn't have courses, but small, linear, curated paths.
        • Marco: Today: The fact that subsections in edx-platform are linear (and that's all that's available) is a limitation Product has run into. If you were to introduce the notion of a type of sequence (linear, adaptive, choose-your-own, explore, etc.)...
          • Sequences in the proposal are the "dumb" version. Adaptive would be implemented by hitting units, and not deal with Sequences.
          • Alternative can be to make it a more general interface and have multiple sequence types.
          • "Pathway" as a term? (many layers, Marco: everything is a pathway)
          • Pathway as the general thing, Linear Sequence as the more specific.
          • Dave: make sure the API and its promises are clear and forward thinking depending on which way we go with Pathways vs Sequences.
          • Determining where things are stored (based on DDD exercises): Content authoring vs Content repository vs Content management
            • Q: Should Sequences be stored alongside BlockStore?
          • Braden: Abstract Sequence - what does the blockstore need to be concerned about?
            • Type (linear, etc.)
            • Storage/settings (order of units, for linear sequence)
            • Units that may be referenced
          • Marco: What vs. How things are consumed (units vs. pathways/seq)
  • Ownership
    • Sequences can have Units from different Collections
    • Publisher associated with a Collection
    • Nimisha: Can ownership be a tag built on RDF primitives? Or more generic in general.
      • Braden: Permissions vs. Ownership in the legal/branding sense. For BlockStore, want to have permissions system be simple.
      • Nimisha: RDF relationships so that we don't have to hardcode one or two layer organizational layout. Can build onto that relationship when sharing.
      • Marco: If it could be Organizations v2, who can author, who can see? (Most of what we have today rolls up to Orgs. It does currently hurt us that we don't support sub-orgs.)
    • Ned: Proposal doesn't include what operations are supported on these data types.
    • Relationship within the Org
    • What happens when you create a Sequence of Units from different Collections?
      • Content could either be public or private.
      • Public content would have license, and be discoverable. Usable in a read-only way.
      • Q: No overrides?
        • A: To keep things simple, read-only or make a local copy if license allows to modify.
        • Marco: We ran into this on libraries. There is a lot of power that would be useful here.
        • Braden: XBlocks tries to do this with settings scope.
          • In the longer term, want to be able to do overrides at the sequence scope or higher level.
    • Braden: look at Git (fixed hierarchy) versus Gitlab (flexible hierarchy)
  • Publishing
    • At what granularity?  Sequence-level or Unit-level?
    • LabX requires both use cases.
  • Ned:
    • Why only units and sequences?  Do we need more?
    • Same issue with organizations.
    • Should we consider having a more flexible and abstraction structure?  Or would that be over-engineering?
    • Braden: OEP input on the use cases.
  • Next Steps:
    • Braden will create a new Google doc, consolidating the latest thoughts, sharing with this group.
    • We'll expect an email from Gaurav and/or Braden early next week regarding opening up the discussions over an OEP proposal.  The OEP may remain in a Draft state while things are being fleshed out.