Agenda & Notes

Curate a list of high-level requirements questions that we have to-date that we can forward to Product/UX.
1. Content Reuse
  1. Units and Sequences as well?
  2. Can authors add/remove units within a Sequence?
  3. Which configuration/settings changes?
  4. References/links
    1. What happens when you create your own overrides/copies?
      1. Original content changes
      2. Permissioning/licensing overrides?
  5. Immutability
    1. What version/portion of a block/unit to be immutable?
  6. Propagating updates from upstream
    1. manual or automatic
    2. types of changes: content, ACLs, etc.
2. Content Composability
  1. Hierarchical composition of sequences?
  2. (Should it be in the blockstore or somewhere else?)
  3. Workflow: for creating course, course-run, composition
    1. Are different teams working on different parts (e.g. problem banks, course)?
3. Versioning
  1. Granularity - unit-level, collection-level?
  2. Authors explicitly specify major versus minor changes
4. Access control
  1. Ownership
  2. Permissions
5. Licensing
  1. Flexibility of types of licenses?
  2. Prevent changes to licenses that shouldn't be allowed - like less restrictive or deleting it?
6. Development
  1. Flexibility of replacing with own implementation of sequences/collections/etc?
7. Migration requirements
  1. Migrating/Copying edx.org courses into Blockstore
    1. licensing
    2. tagging for reuse
BlockStore design collaboration
- Can we break-up the BlockStore design into smaller pieces so we can have focused breakout discussions on each topic?
- Is Confluence working for us? Best practices on making it work? Will it be better once we break-up into separate docs? Or do we need to move to another tool?
Shall we step away and try to reason about this top-down as well?
- For example, go through an exercise of defining the developer interfaces/APIs for BlockStore.
  - Generic APIs
  - LabX use cases
- Go through an exercise of determining the usage of it via composed "Courses", reusable "Sequences", and tagged content.
- As we do this, can we think differently about how the design can be simpler?
Shall we schedule another near-term meeting (maybe 1.5 hours) to do #3 above?

Action Items

Braden MacDonald, @Ian
- Use Case doc for review: https://docs.google.com/document/d/1MqZIsMBIKReapMNmEI35AT7G1Zlc8T2zvQn8qr_KfUs/edit
- Process for Product requirements input: TBD to expand the use case doc to include draft of edx use cases + stories, then Product to review that doc, and work toward signing off on desired high level use cases + stories. Publish doc publicly alongside Blockstore work to include community input / use cases.
- Design document review process: start with high-level use cases, map to architectural components/systems, determine models for each system and do a deep dive, then review the big picture to ensure use cases are met.
Carly Stevens Schedule meeting for next Wed (5/2) for #3 above (top-down design)
LATER Gap analysis of Modulestore and Blockstore functionality
(e.g., no longer have static structure to traverse, xBlocks no longer at each level, lower-level node having access to course settings)

Browser not supported