TOC Meeting Notes - 2024-10-08

Attendees

The Technical Oversight Committee met on Oct 8, 2024 with the following members in attendance:

  • Anant Agarwal (2U)

  • Dustin Tingley (Harvard)

  • Edward Zarecor (Axim) 

  • Ferdi Alimadhi (MIT)

  • George Babey (2U)

  • Nacho Despujol (Instructor Representative, UPV)

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

  • Xavier Antoviaque (User/Learner representative, OpenCraft)

Notes

Additional TOC Membership

During the meeting, there was a brief discussion about augmenting the Technical Oversight Committee (TOC) memberships. However, the conversation did not deepen due to pending discussions with the organization being considered. The commitments should be finalized in the coming days.

It was noted that once these commitments are finalized, an email announcement would be made to the broader community, and subsequent discussions regarding next steps would be held.

Next Steps

  • Continue discussions with the potential new TOC member and finalize commitments.

  • Once finalized, communicate these developments via email to ensure transparency and inform the community about the expanding TOC.

  • Discuss and plan the integration and roles of new members to the TOC in the next meetings, ensuring these additions align with the strategic goals and needs of the Open edX project.

Sidebar Navigation Implementation and Release

There were discussions about the implementation of the new navigation sidebar. It was highlighted that Pearson was initially working on a sidebar navigation which was released in June as part of the Redwood release. Although it is available, it still resides behind a feature flag due to readiness concerns and testing needs. These discussions brought up the importance of having a consistent user experience across different platforms such as http://edx.org and residential systems from institutions. The need to synchronize the user experience to avoid confusion was emphasized, with opinions suggesting that once it becomes the default experience on major platforms like http://edx.org , others would likely adopt it quicker.

Next Steps

  • Engage with the product team to ensure the implementation and readiness of the navigation sidebar across all platforms.

Communication on New Features

There was a consensus on the need for better communication mechanisms regarding new releases and features. It was discussed that significant releases like the sidebar navigation did not have widespread awareness within the community, suggesting a gap in effective communication. The suggestion was to enhance the release announcements on blogs and possibly explore more direct lines of communication like newsletters. This would ensure that valuable additions to the platform are well-publicized and adopted by the community, leveraging the full potential of each release.

Next Steps

  • Explore and implement more robust communication strategies like in-app news notifications and newsletters to inform users and developers about new releases and significant changes, ensuring broader engagement and quicker adoption.

Organizational Commitment and Core Contributor Summit

There was a significant discussion regarding the need for organizations involved with Open edX to commit more actively as maintainers. It was highlighted that while there is a large number of contributors, the maintenance responsibilities are not equally distributed. This imbalance could hinder the platform’s development and sustainability over time.

The conversation focused on the potential for redefining what it means to be a partner within the Open edX ecosystem. It was suggested that being a partner should go beyond merely having a logo on the website but should include tangible commitments to maintaining the platform. The idea of setting expectations for maintenance as a prerequisite for partnership status was proposed.

In light of this, the upcoming summit was mentioned as an ideal opportunity to further this discussion. The summit could serve as a platform to engage directly with providers and discuss the expectations and benefits of increased commitment to maintenance roles - a proposal was introduced to this effect. It was proposed that after the summit, there could be discussions aimed at defining specific maintenance roles and level of responsibilities for partner organizations.

The suggestion was made to start a conversation with the community, particularly with the providers, about what could be committed to in terms of maintenance, and what the community expects out of the partner program. This dialog could help in building a more collaborative and sustainable development environment for Open edX.

Next Steps

  • Presentation of the proposal at the Core Contributor Summit to garner feedback and further refine the approach.

  • Initiating discussions with providers to redefine partnership commitments with respect to maintenance roles. This would involve asynchronous and synchronous communications, potentially facilitated by accessing a mailing list or directly through emails to ensure broad participation.

  • The establishment of clearer expectations and possibly revising partnership agreements to include maintenance commitments as a standard part of the partnership criteria.

Architectural Vision Proposal

In the meeting, the architectural vision for the Open edX platform was discussed again, with a new draft being evaluated, with the goal of establishing an official vision shared by project participants.

The current draft categorizes the platform architecture into different layers: the kernel, the reference product, and extensions or plugins. The kernel represents the core functionalities essential for presenting general education online, like grading and content management. Around the kernel, the reference product is built, providing a more user-specific functionality set, which can still be quite generic and extensible. Extensions or plugins offer customization and additional features that may not be universally required amongst setups using the reference product as a basis.

Participants discussed the boundary between the kernel and additional features or tools that facilitate installation or maintenance. The operator or installer of an instance, which uses those tools, are important users that get less attention from a product perspective compared to instructors or students, but are important for adoption. It was affirmed that such tools, although crucial for user accessibility, may not necessarily reside within the kernel but can be considered critical support tools.

An important question was raised regarding whether tools like Studio, which is essential for course creation, should be part of the Reference Implementation or treated as a separate entity that could potentially be used by other systems. Consensus leaned towards maintaining a tight integration to ensure ease of use for instructors, mimicking the seamlessness of integrated platforms like Moodle.

Next steps

  • A glossary defining terms like 'kernel' and 'reference product' will be included to avoid confusion.

  • The proposal will be adjusted and reviewed asynchronously via email to finalize the shared vision, aiming for eventual integration into OEP-53 and broader community endorsement.

AI & LLM Strategy

The need for a clearly articulated strategy for using Large Language Models (LLMs) with the Open edX platform was strongly emphasized. Compared to competitors like Moodle, which are making significant strides in integrating these generative functionalities, Open edX is perceived to be lagging. The suggestion was made to formulate a working group dedicated to creating an AI strategy, which could involve designing an API layer to facilitate LLM functionalities seamlessly and allow third-party innovations.

Participants discussed possible initial features, such as integrating existing LLM services (like OpenAI) through plugins or APIs, enabling capabilities like automated content generation or enhanced analytics. The importance of allowing self-hosting of open-source LLMs like Llama was also mentioned, to avoid depending on proprietary technology, to ensure data privacy and to reduce costs for users.

Next Steps

  • Forming a working group to develop an AI strategy.

  • The group would consider creating an API layer for integrating AI services, enabling the community and external developers to build and integrate AI-driven tools and functionalities.

  • Open edX community members will be encouraged to provide feedback on the architectural proposal and participate in the AI strategy discussions.