Content Libraries Decision Log
Pending decisions
Settings on imported blocks: What should be preserved in libraries, what should be shown in libraries, what should be copied into courses, and what additional prompts and validations are needed?
6-24 Decision:
All subsection/sections are preserved on import from a course to a library
Settings are viewable but not editable in libraries. UI question as to how.
When these subsections/sections are reused, need messaging for authors to guide any re-configuration needs in the local courses.
Product to-dos:
UI for view only settings in Libraries
UX/messaging for authors to re-configure reused content locally in courses
Write permissions at the content level (instead of library level?)
Approach for “forced V1 migration” in Verawood
Proposed: Make the sidebar a plugin slot when we refactor those into new groupings as part of upcoming UX work.
Rationale: This is a natural extension point and likely one of the more stable elements of the UI.
Long term: Course editing options for Learning Core-based courses?
Are we going to support the exact Course editing experience when moving a course to Learning Core, or will those courses only be editable in a new to-be-built UX? We definitely need to continue supporting some course-centric authoring view, but exactly what this is may be a post-Ulmo exploration/decision. (slack thread)
Log
Jun 3, 2025
Decision: Learning highlights we will treat as a setting that doesn’t get carried over into the library because it is course-specific.
However, we are exploring a learning objective/learning outcome field with library content. Still pending some input from the CBE product discovery this month. The longer term intent is to depr the learning highlights feature and replace it with a better designed and more comprehensive learning objective. Open questions about relationships to tags, etc.
Jun 6, 2025
V1 library migration - Ulmo will be manual/voluntary migration only; need to make a decision for Verawood on approach to auto migration
Need to support library import/export for Ulmo in order to maintain parity with V1 and support migrations
May 30, 2025
Will we need to support granular permissions within a library, e.g. different groups of people having write access to different parts of the library?
Most likely yes, will write up more about this soon.
Dates are preserved on course import into library.
Do we need to inherit down?
Kyle: Why the difference between the things you can edit vs. you can’t in libraries based on whether it’s imported or created in the library?
Marco: Preserving everything on import is the most important thing. Have a place to show these settings is secondary. Figuring out what we allow people to be able to set in libraries is tertiary.
Decision: Preserve all container fields to start, everything is read-only to start, editable later.
Decision: When importing from a course into a library, we do not have to link it, i.e. the newly created subsection in the library does not become an upstream of the course subsection.
Decision: Libraries will not support split test xblock
May 28, 2025:
Subsections/Section settings requirements [LINK to updated PRD - coming soon]
We need to apply an “MVP + phased roll out” approach to tackling subsection and section settings requirements. This is driven by the hypothesis (to be tested in May/June) that there are two categories of subsection/section reuse, each with nuanced setting/configuration needs:
1) Reusing subsections/sections already in existence from courses, and
2) creating new subsections/sections from scratch in a library for reuse later.
We will develop an Ulmo MVP for settings around the former, and address the latter in Verawood.
Ulmo settings requirements:
When a course is imported into a Library, the course-level settings on subsections and sections will carry over in the Library. They will be read-able but not edit-able in the Library. If that subsection/section is reused in another course, the settings can be overwritten locally in the new course. All settings need to be preserved on the backend.
When a subsection/section is created in a Library, the settings will not be settable. When those subsections/sections are reused, the settings can be overridden locally.
The following settings will not be viewable at all in libraries because they don’t make sense (but still :
Change due date
In future releases, we will expand settings in libraries so that they can be edited in Libraries.
References: https://docs.google.com/document/d/1ZxxetJgMXn-aa0ybFDEbm1tE623Nr6TXwk3XTBfgsTo/edit?tab=t.0
copy-pasted from the concept decision log doc, Dave to clean up later:
May 23, 2025
Discussion: https://docs.google.com/document/d/1ZxxetJgMXn-aa0ybFDEbm1tE623Nr6TXwk3XTBfgsTo/edit?tab=t.0
Decision: A container is “last updated” or “last published” whenever one of its descendants is last updated or last published.
Discussion: Generalized idea of “publishing dependencies” as a broader way to describe the kind of publishing relationship between containers and their children (to better support courses later).
Decision: Yes, this language is fine, but it’s probably not going to be exposed to the user except through documentation.