Frontend Working Group Meeting Notes

Frontend Working Group Meeting Notes

You’ll find all the Frontend Working Group’s meeting notes (which include links to recordings) as children to this page.

Each meeting’s agenda is decided in the week leading up to it, and publicized accordingly.

Please use the following template for a new meeting:

 

Previous meetings

Pending action items

Latest Decisions

Title

Decisions

Title

Decisions

https://openedx.atlassian.net/wiki/spaces/COMM/pages/6132760577/2026-03-26+Frontend+Working+Group+Meeting+Notes+Instructor+Dashboard+Verawood+delivery+semantic+releases+and+workspaces

  1. We recommend going with (back-and-forth) redirection for missing features in the Instructor Dashboard

https://openedx.atlassian.net/wiki/spaces/COMM/pages/6013124618/2026-03-12+Frontend+Working+Group+Meeting+Notes

  1. Let’s use turbo in app repos too
  2. We should document every fix/improvement that lands on frontend-base that would make sense to backport to master, and open backport PRs only once they land
  3. “BOTH”: tutor-mfe should support both a built-in frontend-site, and the ability to specify custom, externally managed frontend-site repositories (or, separate SPAs)

https://openedx.atlassian.net/wiki/spaces/COMM/pages/5781585921/2026-02-12+Frontend+Working+Group+Meeting+Notes+The+Alias+Saga+frontend-base+status

  1. We will go ahead with Typescript transpilation before publication
  2. We will update app package exports to include more than just the basics

https://openedx.atlassian.net/wiki/spaces/COMM/pages/5655265281/2026-01-29+Frontend+Working+Group+Meeting+Notes+Frontend+Board+Reorg+Program+Dashboard+and+React+Query+conversion

  1. The group decided to prioritize merging the full React Query migration PR for Learner Dashboard master (led by Jacobo Dominguez) before landing the Programs Dashboard conversion PR (led by Max/Jason Wesson).

https://openedx.atlassian.net/wiki/spaces/COMM/pages/5178359809/2025-08-27+Frontend-base+Release+Strategy+Summit

  1. Operators can deploy converted MFEs optionally, on a per MFE basis, for at least one release, and at most two releases
  2. For a period of time there will be two branches, and at some point there will be only one: the choice should be up to the maintainer of the repo
  3. Development should default to frontend-base ASAP
  4. Support operators who use master to be able to choose and test frontend-base
  5. Coordinate with individual maintainers on how the frontend-base branch evolves
  6. Communicate to current maintainers things they should/shoudn’t do that will make porting to frontend-base easier
  7. Library upgrades such as react-router from v5 to v6, or react-query from v4 to v5, should happen in master before the frontend-base branch
  8. Do not start converting any new MFEs until the missing features have been tackled, and based on that, a new decision is arrived at on whether any new MFEs will be converted at all for the following release
  9. Any newly developed MFEs that are targetting Verawood or beyond should be developed on frontend-base only