[Draft] edx-platform Architectural Roadmap

[kdmccormick]

About

This is a place to coordinate long-term technical work within the edx-platform repository for the benefit of:

• Developers of edx-platform core
• Developers of edx-platform extensions
• Site Operators

This work will be completed by a variety of means. It will include both volunteer contributions as well as funded contributions. Some items will be accomplished as part of other feature work, others by their own focused projects. The purpose of this roadmap is not to make the work happen, but rather align all edx-platform developers around a shared vision which can collectively accomplish over time.

Out-of-scope: We will not track tasks that are entirely outside of edx-platform. We will not track improvements for Authors or Learners here. The Platform Roadmap is the right place for those.

Where does this come from? Originally, this Google Doc. Going forward, the roadmap will be managed by edx-platform Maintainers with input from edx-platform Core Contributors.

What's the status? We are still building this out. Stay tuned.

Roadmap Epics

MAKE IT SMALLER (maintenance burden, build size)

Beta Give feedback

1. Complete the MFE conversion process for edx-platform #31620
   3 of 18
   initiative +1
   

   
2. Extract non-Core apps into Hooks-based platform plugins
3. Enforce restrictions on new apps and new dependencies (prior work: no-new-apps ADR)
4. Whittle down requirements list (continuing Braden's work on kernel.in)
5. Migrate ModuleStore off of MongoDB platform-roadmap#3
   operational-impact +1

MAKE IT FASTER (for learners, educators)

Beta Give feedback

1. Once we’ve switched over to Learning Core data models for courseware content access, investigate our memory/CPU usage and optimize to reduce the costs of running the platform.
2. (There have got to be more items we can add here -- will page Dave when he's back from PTO :)

MAKE IT EASIER TO CONFIGURE (for devs, ops, admins)

Beta Give feedback

1. [DEPR]: Paver #34467
   17 of 20
   depr +1
   
2. [DEPR] Devstack public-engineering#247
   2 of 8
   depr +1
   
3. [DEPR]: Dockerfiles and Docker images public-engineering#263
   depr +1
   
4. Let's talk about OEP-45 (Configuring & Operating Open edX) open-edx-proposals#587
   under discussion +1
5. Greenfield prod-ready Django settings without YAML #35146
   +0
6. Refactor existing settings files without changing their behavior?
7. Invert or remove Waffle flags that Tutor already enables
8. Switch to Redis by default for caching.
9. Support bare-metal edx-platform
10. Simplify logging config (also see A draft for making a decision on managing logging configurations  #28603)

MAKE IT EASIER TO INTEGRATE (for "external" devs)

Beta Give feedback

1. Document HTTP API support levels, map them to audiences (Operator vs Instructor vs Learner), and map them to product features
2. Define which Python APIs are supported
3. Define best practices for how to build HTTP APIs (starting point)
4. Clear documentation for how to integrate with external auth providers vs internal.
5. Improve/document AuthZ including documenting the roles that exist in our platform.
6. Either model the catalog in edx-platform or make edx-platform oblivious to it (starting point ADR)
7. API Improvements #32609
   2 of 6
   +0

MAKE IT MAKE SENSE (for "internal" devs)

Beta Give feedback

1. Consolidate to a single edx-platform docs structure.
2. Repo Structure: Define the structure of edx-platform as it stands today, define the structure of the repository that we want (incl. LMS vs CMS concerns), make a plan to get there for existing code, document where new code should go, and use importlinter to help enforce all of this
3. Type hint edx-platform's major packges, add more type hints to edx-platform, and then make type checking opt-out instead of opt-in
4. Turn in-repo apps that are edx-django-plugins into normal Django apps.
5. Resolve various Auth Challenges, including switching all HTTP APIs to use DRF with standard Auth classes
6. Improve edx-platform docs and discoverability #35014
   +0
   
7. Create ADR for avoiding use of plugin patterns where they are not needed #35898
   +0

MAKE MODULESTORE GO AWAY (various benefits)

Beta Give feedback

1. Libraries Relaunch - Component Reuse and Improved UI platform-roadmap#327
   +0
   
2. edx-platform XBlock Extraction #34827
   3 of 9
   epic +1
   
3. XBlock 2.0
4. Limit ModuleStore usage to just CMS and Courseware (implementing Dave's ADR)
5. Limit Modulestore usage to just CMS
6. Finish purging remnants of XModule system, including renaming to make the system more comprehensible
7. Try to reimplement Course Blocks API on top of Learner Core (allowing removal of block transformers)
8. Deprecate XBlock children above the Unit
9. Deprecate XBlock children (period) -- requires replacing dynamic blocks with Learning Core systems
10. Migrate courses from ModuleStore to Learning Core

MAKE IT MORE RESILIENT (needs work)

Beta Give feedback

1. Don't allow error pages to raise errors #35216
   +0

[feanil]

Notes from discussion at Axim:

• It would be useful to make sure we make dependencies clear when we flesh this out into tickets.
• If it's possible to put in any sizing info, that would also help. Are there any quick wins?

[kdmccormick]

Notes from edx-platform maintenance meeting:

• Benefit to add: Making it more resillient (for operators)
  • Example problems:
    • Migrations that are not atomic that cannot be reversed
    • course-discovery requests taking down the LMS
    • genreally, less likely to fall down for mysterious reasons
  • Will page Dave once he's back on PTO
• Project management?
  • Turn top-level groups into labels so we can prioritize the list
  • Sizing labels
  • Not a board, since this isn't a cohesive project