Attendees

The Technical Oversight Committee met on Nov 12, 2025 with the following members in attendance:

• Dustin Tingley (Harvard)

• Edward Zarecor (Axim) 

• Ferdi Alimadhi (MIT)

• Jeremy Ristau (2U)

• Nacho Despujol (Instructor Representative, UPV)

• Régis Behmo (Operator & Core Contributor Representative, Edly)

• Xavier Antoviaque (User/Learner representative, OpenCraft)

Executive Summary

TOC Election: The candidate slate was unanimously approved, with voting opening within 24 hours.

Conference Planning: Planning progresses with confirmed details, though visa barriers may prevent some international participation. Broad support emerged for including student and instructor voices at the event.

Notification Framework: A proposal for community notifications within Open edX generated substantial debate. Strong institutional concerns about direct learner communication led to consensus that notifications should target site administrators rather than end users.

Deployment Strategy Shift: 2U is making a significant change from continuous deployment off master branch to named release branches. While this accelerates community merge velocity, it eliminates immediate production feedback from a very large instance, requiring stronger automated testing.

Release Management: Significant interest emerged in increasing release frequency from twice-yearly to potentially monthly releases with smaller change sets. A proposal was made to engage external release management expertise and form a task force to improve processes, including enhanced testing infrastructure and streamlined upgrades.

Approval of TOC Election Candidate Slate

The slate of candidates for the TOC election was presented, including several familiar community members and one relatively new person from a major educational institution. The charter allows mission-aligned organizations to put forward candidates, with a cap of three members from any single organization. The TOC's responsibility to approve the candidate slate serves as a protective measure to prevent potential hijacking or inappropriate candidacies. The present members unanimously approved the slate of candidates without objections, and voting would open within 24 hours.

Announcement: Large-Scale Aspects Implementation Case Study

A new case study was highlighted about a major institutional user's extensive use of the Open edX platform. While not yet fully approved for wide sharing, it was available for internal review within organizations. The institution had adopted the Aspects data platform extensively, using thousands of CCX sections for their courses. They had imported approximately 4 billion legacy events into Aspects and were generating around 1.5 million new events daily, making them by far the largest known instance of Aspects. The project's support organization had been working closely with this institution to address performance issues that naturally arose at such scale.

Conference Planning and International Travel Concerns

Conference details had been finalized, with information about dates, location, and hotels available. The event composition might differ from previous years, with signals suggesting some international colleagues were less enthusiastic about traveling to the U.S. than in the past, while there appeared to be significant interest from new attendees, particularly those wanting to connect with a co-hosting institution.

Concerns were raised about visa denials based on news reports. Data was shared from institutional tracking at scale, reporting that visa issues had not materialized as a problem this semester for students from Asia, Africa, and most regions, though certain countries would face more scrutiny. It was noted that some countries had faced challenges even at the previous year's conference, with visa appointments being difficult to secure. Historical success rates bringing colleagues from certain regions to the U.S. had been 0%, both historically and currently. Some members of the community would likely face real barriers, including those from several Latin American countries where community members had engineers.

Student Participation at Conference

The idea of including student voices at the conference was proposed, potentially through a roundtable or panel discussion with students who had learned on the platform. It was acknowledged that the community had fallen short in including student perspectives at previous events. Support was expressed for this idea, with suggestions to also extend to instructor participation. The notification framework being discussed could potentially be used to reach out to learners and inform them about the conference.

Various implementation approaches were discussed. Options included having either a panel discussion with 3-5 hand-picked students or a town hall format that might allow broader participation. Questions were raised about whether the goal should be gathering feedback specifically at the conference or more generally from students throughout the year. Interest was expressed in potentially having students from various institutions participate in such an initiative.

Notification Framework Discussion

A proposal was presented for implementing notifications within the Open edX platform to communicate with the broader community, including learners and instructors. The proposal originated from the product working group's need to test features and gather user feedback. Currently, the community lacks effective means of reaching out to learners and instructors who actually use the platform, beyond the relatively small number of people who read the Open edX blog.

The proposal involved integrating community notifications into the existing notification system within Open edX, controlled centrally through RSS feeds or the Open edX WordPress site, similar to how the blog is managed. These notifications would appear in users' notification trays and could link to surveys, forum threads, or other feedback mechanisms. Examples were cited of other software platforms that use similar approaches for release notes and feature announcements.

Note that this proposal is distinct from the notification capability that was added to the platform for the Ulmo release. Originally developed by 2U, that capability has been improved upon over the last few months, to make it more general purpose, less specific to 2U and more configurable. 

Concerns Raised

Several implementation concerns were identified, particularly around language translation (as messages would need to be available in multiple languages) and the need for platform administrators to gate and approve notifications before they reached their users. Administrators would want to at a minimum review and potentially edit messages before distribution. 

More broadly, institutions want to be in control of their communication and branding with their users. Strong reservations were expressed about Open edX communicating directly with learners rather than through site administrators. Arguments were made that Open edX should function as a platform rather than a product, and that many organizations customize Open edX extensively. If such a feature were implemented, notifications should go to site administrators rather than directly to learners. Institutions were currently building their own plugins for gathering user feedback on various topics specific to their product needs.

Concerns were raised about brand separation and the potential for confusion if Open edX communications bypassed the instance-specific or institution-specific barriers. If the implementation involved individual notification entries, gating and review capabilities would be needed. An alternative was proposed where notifications might link off-platform to a separate announcements page, which would provide more control.

Strong concerns were echoed about having third parties communicate with learners in ways not filtered through institutions. Learners are primarily focused on learning specific subject matter, not on the Open edX platform itself, and institutions curate their own communities. Feature requests might be an exception where learner input would be valuable.

Alternative Approaches Discussed

Suggestions were made to create a community of interested administrators and/or instructors rather than trying to reach all learners. At many institutions, most instructors would ignore such communications, but a small number are very active and interested in new features. Information could be sent to administrators who could inform their instructors, allowing interested instructors to opt into a community forum for ongoing engagement.

Support was expressed for this approach, noting that organizations target authors and instructors for qualitative feedback while using observational data and small surveys for learner feedback. Release notes had been implemented in the authoring interface, and the instructor and authoring interfaces might be more appropriate places for community engagement.

To gather feedback from students, it was noted that the one-way notifications would need to be complemented with links to a two-way communication channel like a forum, or to surveys. 

Acknowledgment was given to the feedback, recognizing that administrators from large instances weren't interested in having their communications bypassed. It was agreed that a first step should be notifications to administrators rather than to learners, with potentially tools to allow the administrators to involve instructors. It could help build trust and establish the system before potentially expanding it. There was still believed to be value in connecting the broader community to the project, even if the implementation needed refinement.

The philosophical divide was summarized, noting that some view Open edX as a product while others view it as a platform that powers products built by institutions. Open edX's relationship should be with site administrators, and if feedback was needed on specific topics, it should be requested through administrators who could then engage their users appropriately.

Major Platform Provider Deployment Changes

A significant update was provided about deployment practices. Historically, http://edx.org ’s production instance had deployed from the Open edX master branch for the platform and main branches for micro-frontends, using a CI/CD system that automatically deployed merged PRs to production. This approach had created barriers for major changes that required infrastructure they couldn't prioritize immediately, and the instance could be immediately impacted by any issue introduced by merges to master from other community members.

Around the time of the recent release branch cut, internal forks were created and deployment began from the named release branch instead of master. This change applied to the main platform repository, front-end applications, and some backend services. Going forward, deployment would occur from named release branches rather than master. For the upcoming release, plans included establishing shadow environments for validation with large datasets and building out a more robust suite of automated tests to validate priority use cases, particularly those not covered by the Build Test Release working group.

Important context was added about the implications of this change. Previously, getting 2U’s review before merging to master had sometimes delayed community contributions, as these reviews depended on staff availability and priorities. The instant deployment to production also meant there was no buffer to implement fixes. The new approach would allow the community to move faster on merging changes to the latest release. However, it also introduced new risks, as the community would lose the immediate feedback from a very large instance that helped identify problems and performance issues before releases. This feedback had provided confidence that code was battle-tested by the time a release cut occurred.

The community would need to develop confidence through improved acceptance testing, integration testing, and automation. The Build Test Release working group and several major institutions were all interested in strengthening testing capabilities, and the challenge was coordinating collaborative efforts to build extensible test suites. These would include base tests plus additional instance-specific tests that large deployments could run.

Release Management Discussion

The deployment changes sparked a broader discussion about release management processes. Several questions needed addressing: whether two releases per year was the right cadence, whether an LTS (Long Term Support) release model should be adopted, and how to handle expand-and-contract database migrations with potentially longer gaps between releases.

Strong arguments were made for more frequent releases, suggesting that everything pointed toward a faster release pace. More frequent releases would reduce the size of changes in each release, making internal fork management easier since organizations wouldn't be working against code from 6 months ago. Release frequency similar to other open source projects—somewhere between weekly and monthly—would be appropriate. It was emphasized that it was more important to be able to fix issues quickly than to prevent all bugs beforehand, and that more frequent releases would help with security patches.

Support was expressed for this perspective, noting that smaller deltas between releases and exercising the deployment process more frequently would strengthen organizational capabilities. More frequent releases might also eliminate the need to backport security patches between major releases.

Questions were raised about whether the vision was for point releases within an LTS model or for a strategy with many releases per year. Clarification was provided that the thinking was toward the latter, suggesting one minor release per week to per month was typical for open source software, though weekly might be too frequent for Open edX.

Important concerns were raised about adoption rates. Even with two releases per year, community members often requested less frequent releases. Introducing an LTS model might result in everyone following only the LTS releases, effectively reducing update frequency rather than increasing it. Questions were posed about how the community could ensure significant adoption and upgrade rates, suggesting this might require making releases easier or implementing some form of auto-updates.

Responses noted that a particular deployment tool could help address this, making it easier to notify users of new versions and potentially send emails to users. The satisfying experience of clicking an upgrade button (like in other content management systems) was contrasted with the current anxiety-inducing stop-the-world Open edX upgrade process. If upgrades were smoother, with more frequent releases containing smaller changes, people would be more likely to upgrade rather than viewing it as a risky endeavor.

Further support was expressed for tools to reduce upgrade anxiety, such as dry run capabilities or better feedback about whether an upgrade would succeed. Organizations were currently anxious about the next major release because they wouldn't know about potential downtime or issues until very close to the actual upgrade.

Agreement was expressed about the goal but noting diminishing returns for centralized testing, as instance-specific configurations could cause failures that centralized tests wouldn't catch. However, work on optimizing upgrades in one deployment method would provide valuable lessons applicable to other deployment approaches as well.

A proposal was made to find someone with release management experience from outside the community, ideally from a large, complicated open source project, who could review Open edX's current processes and make proposals for improvement. A task force would also be constituted to work on this topic.