Contributors Meetup Async Update - Nov 8th - Nov 21st, 2024

Working Groups Core Contributors
,
1

Core Contributor Update: Nov 8th - Nov 21st, 2024

Use the jump links below to view the section that interests you:

  1. Working Groups Updates
  2. Events
  3. Projects
  4. Next async update and meetup

1. Working Groups Updates

Working Groups Calendar

1.1. BTR Working Group

Chair: @jalondonot

:paperclip: Latest news

:memo: Meeting notes

1.2. Contributor Coordination Working Group

Chair: Jorge Londoño

:paperclip: Latest news

  • Time Confusion
    • Cassie and Xavier discussed the confusion created by a recent timezone change which coincided with a change in meeting links, causing attendees to either join meetings late or misjudge their timing. Xavier noted problems with calendar syncs when official calendars are updated without syncing the individual’s copies, causing further confusion. They noted the need for a better system though no solutions were proposed immediately.
    • Cassie Zamparini discussed the polling system to use for the voting process, which was due to begin the following week. She emphasized the ease of a simple voting system could improve involvement but also raised concerns about ensuring only core contributors were eligible to vote. Xavier suggested using existing tools like forum surveys to keep the process contained to contributors only. Cassie also proposed a timeline for the voting, suggesting an announcement be made in the current week to prepare members and to set a voting period of two weeks to accommodate any contributors who might be unavailable in a shorter timeframe.
    • To increase involvement and feedback on the proposals before the voting began, it was planned to remind and encourage core contributors to review the proposals actively and provide comments to foster productive discussions.
  • Next Steps
    1. Implement a simple polling system for voting, ensuring that only core contributors are eligible to vote.
    2. Cassie Zamparini to announce the voting schedule within the week to prepare contributors.
    3. Direct follow-up with proposers who need to clarify their summit proposals before voting.
    4. Plan to use the existing ticketing system for tracking project progress post-vote, ensuring all updates are meticulously documented.
    5. Encourage thorough testing and review of proposals by all core contributors.
      Meeting participants left with clear tasks and timelines, looking towards an efficient voting process and subsequent implementation of the summit’s outcomes.

:memo: Meeting notes

1.3. Data Working Group

Chair: @e0d & @blarghmatey

:paperclip: Latest news

:memo: Meeting notes

1.4. DEPR Working Group

Chair: @feanil

:paperclip: Latest news

:memo: Meeting notes

1.6. Tutor Users’ Group

Chair: Kyle McCormick

:arrow_down: Past meeting notes Tutor Users GW 2024-10-21

:memo: Meeting notes

1.7. Educators Working Group

Chair: @john_curricume

:arrow_down: Past meeting notes 2024-10-07 Educator WG

  • In this session of the Open edX Educators Working Group, Eric J. Larson discusses AI literacy, focusing on the distinction between AI capabilities and human-like reasoning. Participants, primarily educators, explore the implications of AI in education, emphasizing the potential and limitations of current AI technologies. Larson elaborates on his book ‘The Myth of Artificial Intelligence,’ highlighting the strengths and weaknesses of AI as an educational tool. They discuss issues such as hallucinations, the impact of AI on student learning, and the importance of maintaining critical and creative thinking. Larson promotes leveraging AI thoughtfully to complement human cognitive abilities, especially in educational settings, while acknowledging the inherent challenges and unpredictable errors of AI systems.

:memo: Meeting notes

1.8. Frontend Working Group

Chair: @arbrandes

:arrow_down: Past meeting notes 2024-10-24 Frontend Working Group Meeting Notes

  1. Front End Base Initiative:
  • David Joy introduced “frontend-base,” a single, unified library to replace various frontend components, including headers and footers. This initiative aims to improve configurability and usability across different platforms.
  • He demonstrated the new header and footer functionality, showcasing customizable, component-driven configurations for headers that replace previous complex implementations.
  1. Header Configurations:
  • The new headers, configured within a “site config” file, allow flexible and dynamic updates across modules, reducing the need for major code adjustments.
  • David highlighted that headers can now respond dynamically to module-specific requirements, such as different links for studio or learning environments.
  1. Footer Development:
  • David presented a prototype for a more versatile footer, inspired by popular layouts like those seen on edx.org, aiming for adaptable, structured link layouts and improved internationalization.
  1. Module Federation and App Configuration:
  • David introduced three ways to configure applications: internal apps, federated modules, and external apps, each with different deployment options to support modular, flexible builds across platforms.
  • Discussion covered the possibility of modules automatically providing default configurations for ease of integration and reducing the need for manual configuration.
  1. Plugin and Module Slot Configurations:
  • The team debated how plugins and modules should be organized for optimal flexibility and ease of configuration. They aimed to find a balance between granular configurability and simplicity.
  • Suggestions included creating helper functions and default configurations to streamline the configuration process for users unfamiliar with frontend development.
  1. Internationalization Improvements:
  • David shared updates on improving language selection for the platform. The new footer will use updated browser APIs to display language options based on actual translations configured in the system, removing the need for large external libraries.

Outcomes and Next Steps:

  • The group expressed overall approval for the proposed configurations and recommended further testing to explore complex use cases.
  • David will summarize the current work and gather additional feedback on Discourse.
  • The team acknowledged the importance of balancing configurability with usability and agreed to continue refining the system.

:memo: Meeting notes

1.9. Large Instances Working Group

Chair: @braden & @Felipe

  • eduNEXT:
    • Moisés González : We have been focused on upgrading to Kubernetes 1.31 and testing our tools for the Sumac release, which has changes like the new forum and using Meilisearch by default.
    • Felipe Montoya Asked about whether or not the new forum will be default in Sumac. Apparently the PR has not yet merged to master. A big concern is the upgrade path and the migration of data from MongoDB into MySQL (which is encouraged but not required as the new forum can use either MongoDB or MySQL).
    • eduNEXT is interested in helping to test the forum v2 and the upgrade pathway.
    • Jhony Avella Is the new forum v2 using Meilisearch or Elasticsearch? A: seems both
    • Felipe Montoya Mentions that based on recent project requirements, he has put forward Lightweight catalog implementation via extensions and is looking for feedback. Hoping to build something that works for these two projects and the broader community, and may be able to build it before the end of the year. Hoping to collaborate with anyone who is interested, though due to deadlines, will need to build something like this either way.
    • Jhony Avella We merged the PR to update the Helm chart dependencies, though a couple like OpenFAAS and Velero still need to be updated. Also renovate opened quite a few version update PRs. Open Question: Is it possible to change renovate to open a single PR with all the version bumps?
  • Question: What is our policy on merging these PRs? Jhony Avella suggests we need to get the integration tests in place first.

OpenCraft:

  • Gábor Boros has been working on porting the Terraform scripts that we have into Harmony. Also, approved the version bump PRs. Will be opening a PR soon to bump OpenFAAS and Velero.
  • Discussion around Sumac requirements and how to run Meilisearch for large instances. Should there be one Meilisearch instance per index, per Open edX instance, or per Harmony cluster?

Discussion

  • Braden MacDonald Brought up the Sumac release and testing process, asking if there’s a way to get more developers involved in fixing bugs. @Felipe Montoya mentioned that eduNEXT is re-organizing some internal teams but soon one of them will be heavily involved in the testing and bugfixing process.
  • eduNEXT mention they’re using an annual upgrade strategy, where most customers will be on Redwood, skip Sumac, and then upgrade to Teak next year. But eduNEXT will still be participating in the Sumac bug testing process.

:memo: Meeting notes

1.10. Marketing Working Group

Chair: Eden Huthmacher

:arrow_down: Past meeting notes 2024-09-18 MWG Meeting Notes

:memo: Meeting notes

1.11. Maintainers

Chair: Feanil

:paperclip: Latest news

  • Frontend-app-authoring issues and libraries:
  • Follow up from https://axim-collaborative.slack.com/archives/C04BM6YC7A6/p1731658458397369Conecta tu cuenta de Slack
    • We’re using the repo’s issues both for task tracking for content libraries and for bugs and features coming into the rest of Studio.
    • That has made it harder for the maintaining team to pay attention to both the issues and bugs coming in as well as just managing the content?
      • Is that how we want workstreams for repos to work?
        • Would labels or tags help?
          • Labels per project might be useful so that we could filter out issues tied to an active workstream.
            • ie. if bug/issues related to an active project are tagged
  • It makes sense to have the high-level epics stay on the platform-roadmap repo, but it would be useful to link to that from all the READMEs
  • We can filter based on projects eg. ignore all tickets that are on the libraries overhaul project:
    • is:open is:issue -project:openedx/66
    • No other projects: is:open is:issue -project
      • Is this what the maintainer should be looking it.
      • If you have a lot of activity you may need something like this to filter out work that already have active folks looking at it.
      • is:open is:pr -project project:openedx/19 -label:FC
  • What about bugs? Do the repo bugs go in public-engineering or stay in the code repo?
    • Keep the bugs in the FC issue list but if the FC closes move the bugs into the relevant code repo.
    • Testers will file bugs where they file them and we’ll triage and move as necessary.
  • (Time permitting) Devstack settings deprecation
    • [DEPR] Devstack · Issue #247 · openedx/public-engineering
    • Tutor’s dev settings are a thin layer on top of its common settings overrides, which are always used with the yaml-based production.py. That means that “rebasing” Tutor’s dev settings on to yaml-free common.py actually adds a ton of complex differences between Tutor’s prod and dev, not to mention that it would break any tutor plugins that used yaml overrides.a
    • It seems that if we’re going to rebase tutor’s dev settings onto common.py, then we should do the same tutor’s prod settings, and couple it together with a broader yaml deprecation. That does majorly increase the scope of this effort, probably turns it into a next-year project. Curious if you agree or if there’s any small-bite work that you think I’m missing.
  • Discussion about a potential new ADR

:memo: Meeting notes

1.12. Product Working Group

Chair: Jenna Makowski

:paperclip: Latest news

  • LTI
  • UX/UI Working Group
    • ASU Graded Discussions: interest in learning from previous graded discussion effort associated with EduNext
    • EduNext created a previous graded discussion XBlock; unsure of backer for that project
    • Topics coming up soon (bolded topics are a good fit for next meeting)
      • In next 1-2 weeks, should be ready to share out updates on mobile course content view / visual course progress
      • Sequence navigation
      • Mobile notifications
      • Visually configure content blocks

:memo: Meeting notes

1.13. Security Working Group

Chair: Feanil Patel

:memo: Meeting notes

1.14. TOC

Chair: Ed Zarecor

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.

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.
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.

:memo: Meeting notes

1.15. Translation Working Group

Chair: Eden Huthmacher

:arrow_down: Past meeting notes 2024-11-06 Translation WG Meeting notes

:memo: Meeting notes

2. Events

  • Would anyone like to highlight any past or upcoming events? Let us know in the comments!

3. Projects

Are there any new or ongoing projects you’d like to discuss? Get the conversation started in the comments below.

4. Next async update and meetup

  • Tuesday November 26th - Join the meetup here!
  • Friday December 6th - Async update
  • Details and draft agenda on Confluence

:speech_balloon: Anything to add?

If there’s anything else you’d like to mention, please let us know in the comments below.