How many users have in-flight password reset requests? Do we need to wait for them to clear between going from 1.6 to 1.7?
Currently, splits assumes that the structure document should contain all Scope.settings
fields. However, that makes that document quite heavy. Instead, we could move to a strategy of only inlining particular fields that we know are used during course navigation.
Teams are moving forward on deploying new processes. We need a plan for documenting how these processes should be built, so that all of the new things being built stay relatively consistent.
There are many ways to unexpectedly shoot ourselves in the foot with bad call patterns into modulestore (or bad access patterns when working with XBlocks). We should do some discovery on how to make it easier to fall into a pit of success when using XBlocks, performance-wise.
We have a number of XBlocks that have (for instance) fields with the wrong scope, or many fields for the same data to handle old version of the data in storage. Having a framework for isolating the code that needs knowledge of old formats would make it significantly easier for other teams to make changes to XBlocks without having to worry about backwards compatibility in future code.
The Video and Capa XModules are particularly bad instances of this.