Contributors Meetup Async Update - May 25th - Jun 7th , 2024

Core Contributor Update: May 25th - Jun 7th , 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

  • Testing Progress and Challenges Discussed: Jorge reported that the current status of the testing was at 76%, with a goal to finish all testing by the upcoming Friday. Peter clarified that the main challenge was getting team members to complete their respective tests. Jorge questioned if there was a need for additional manpower to meet the goal.
  • Test Assignments and Release Management: Peter agreed to follow up on assigned tests and identify any blockages. Jorge committed to reaching out to the team members who had been assigned tests to assist them in case they were facing issues. Max and Maria shared their work on tests and identified potential issues, particularly with Android and MFEs.
  • Release Lockers and Open Issues: Maria expressed concern over two release blockers, one related to the sidebar and another to account MFA regarding translations. She confirmed that no other release blockers were found and she would focus on the current open issues. Jorge requested the URLs of these blockers for meeting notes visibility.
  • Maintainers Assistance and Release Blockers: Maria reported that she had been in contact with some maintainers to seek their assistance. Jorge noted that the team had reached more than 70% progress in the testing process and highlighted the need to address release blockers. He proposed to check the status of pending testing cases and to reach out to the respective individuals for support. Jorge also committed to increasing visibility on reported release blockers and to check in with Chris. No other issues were raised by Peter or Max.

:memo: Meeting notes

1.2. Contributor Coordination Working Group

Chair: Jorge Londoño

:arrow_down: Past meeting notes 2024-05-14 CC Working Group Meeting Notes

  • MFE Footer Links and Customizations: Xavier highlighted the need for help regarding MFE footer links and customizations. Ed suggested reaching out to Adolfo who is actively working with others on plugin slots and updating components. However, it was noted that Braden might have already answered a related question. It was agreed that the information would be included in the notes, with a mention for Ali to provide further insight.
  • Increasing Partner Contributions for Maintenance: Xavier and Ed discussed the need to increase contributions from partners to meet the maintenance demands. Xavier mentioned the significant gap from the target of 1020 full-time hours per month. Ed suggested a scheme to classify repositories into three levels of complexity to better estimate the workload. He planned to discuss this with Feanil and assess the uptake from people offering support for main maintenance. There was a mention of some pushback regarding a particular ticket, but the specifics were not clear.
  • Community Involvement and Transition of Roles: Ed agreed to take on additional responsibility and report back on it. There was a discussion about the need for more involvement from the community, with Xavier encouraging members to contribute more. The pair also talked about the transition of roles and responsibilities, and the need to provide more clarity on what is expected from contributors.
  • Project Release and Survey Discussion: Xavier, Ed, and Cassie discussed the community’s recent project release, highlighting the group effort and organization involved. They also discussed the ongoing survey about the call sprint check-in, with Xavier expressing concern about the low response rate and the need to analyze the data. The team decided to give more urgency to the survey by setting a specific deadline. They also discussed the use of Otter as a communication tool, acknowledging its complexity and potential privacy issues, and agreed to postpone its resolution for later. No other significant topics were raised.

:memo: Meeting notes

1.3. Data Working Group

Chair: @e0d & @blarghmatey

:paperclip: Latest news

  • Aspects Product Release Notes and How-Tos for Course Delivery Teams and Superusers; Setup Documentation for Site Operators to follow:
  • Collecting feedback on Aspects: Watch out for a form in the Data WG meeting soon!
  • Aspects extension options: Looking for options to extend aspects with third-party plugins.

:memo: Meeting notes

1.4. DEPR Working Group

Chair: @feanil

:paperclip: Latest news

:memo: Meeting notes

1.6. Tutor Users’ Group

Chair: Kyle McCormick

:paperclip: Latest news

  • MFE build time (below)
  • Configuring open edx services with tutor
    • Moises and Maksim work on large instances group
    • Some of tutor’s default were meant to simplify setup
    • For large instances, they need to undo tutor’s defaults
    • example: celery queues
      • tutor uses one celery queue
      • at scale, the queue can fill up
        • using patches, large instances has been undoing tutor’s configuration changes
    • edx-platform is complex to follow, with all the indirection
      • related: OEP-45 simplification
    • could be better to have a blank slate
    • edunext had to replicate ansible installation settings, using tutor
    • they are using settings patches
  • Having plugins expose configuration interfaces
    • tutor-contrib-pod-autoscaling
    • rather than add more config settings, the plugin

:memo: Meeting notes

1.7. Educators Working Group

Chair: @john_curricume

:arrow_down: Past meeting notes 2024-05-20 Educator WG

  • DJohn Swope, Education Technology Specialist, Chair at St. George’s University AI in Higher Education committee, Author of Micro AI Apps in Online Education: Impacts on Efficiency, Quality and Future Directions to discuss 5 Lessons Learned Building AI Assessments.
  • Assets:
    1. 5 Lessons Learned Building AI Assessments (Presentation)
    2. Open Source Templates
      a. Assistant Template - For phased interactions with an AI that involve user input, AI feedback, and optional AI scoring. Can build things like case study reviews, writing feedback, AI debates, etc.
      b. Completion Template - For one-off interactions with an AI, like generating MCQs
    3. Demo Apps
      a. Guided Case Study : A case study review where students review a case study, critically reflect on it, and receive AI-generated feedback that is guided by what the faculty thinks is important about the case study.
      b. Writing Feedback : A writing exercise where a student drafts an introduction paragraph for a grant application. Again, they receive AI-generated feedback that is guided by what the faculty thinks is important to include in their writing. They then have a chance to revise their original draft.
      c. AI Debate : A student has a chance to engage in a debate with AI (in this case, about Digital Health in Medicine as the topic). The AI is guided to debate the student for two rounds and then summarize lessons learned and good points made by the student.
      d. MCQ Wizard : Generate MCQ questions with optional feedback and hinting based on faculty requirements.

:memo: Meeting notes

1.8. Frontend Working Group

Chair: @arbrandes

:paperclip: Latest news

  1. Discussion on Backporting Footer Slots:
    • Brian Smith discussed backporting the footer slot to Redwood and raised the question of whether front-end slots should be provided by the front-end platform.
    • The group debated the advantages of small, independent repos versus consolidating everything under the front-end platform.
    • Key considerations included maintainability, ease of understanding, and the ability to move quickly with changes.
    • It was generally agreed that while there is merit in consolidating for stability, maintaining separate repos might still be preferable to allow faster iteration.
  2. Frontend Plugin Framework vs. Frontend Platform:
    • Discussion on whether the front-end plugin framework should be integrated into the front-end platform.
    • Concerns were raised about dependency management and potential breaking changes.
    • The current stance is to keep them separate to allow flexibility and faster development until a more stable API is needed.
  3. Modularity and Federated Modules:
    • The conversation touched on the future of modularity, particularly the possibility of federated modules becoming another plugin type.
    • The idea of integrating certain elements into the shell app instead of the library was considered to reduce complexity.
  4. New Contracts and X Blocks Development:
    • Fox Piacenti raised a concern about new contracts requiring the development of new X blocks.
    • Current limitations in integrating new MFE technologies with X blocks were discussed, highlighting the challenges of performance and maintainability.
    • The team acknowledged the need for an updated approach but recognized that a short-term solution would involve creating new X blocks with the existing framework.
  5. Configuration vs. Plugin Slots:
    • Adolfo Brandes initiated a discussion on the use of feature toggles versus plugin slots for configurations.
    • The group explored the benefits and drawbacks of each approach, considering user experience and maintainability.
    • There was consensus on the need for an easier way to discover and manage plugins, potentially through a catalog or admin panel.
  6. Frontend Study Group and Knowledge Sharing:
    • The idea of creating a Wiki page to document and share examples of plugin slots and their usage was suggested.
    • This would help make community contributions more discoverable and facilitate knowledge sharing.
  7. Automated Communication Engine (ACE):
    • Brief mention of an issue related to notification widgets in the ACE framework.
    • The team decided to look further into the issue and explore potential solutions.

Next Steps:

  • Brian Smith to continue exploring the backporting of the footer slot to Redwood.
  • Adolfo Brandes to follow up on the potential integration of the front-end plugin framework into the front-end platform.
  • Fox Piacenti to address the immediate need for new X blocks development while keeping an eye on longer-term solutions.
  • Team to consider creating a Wiki page for documenting plugin slots and examples.
  • Further investigation into the ACE issue and potential impacts on current projects.

:memo: Meeting notes

1.9. Large Instances Working Group

Chair: @braden & @Felipe

:paperclip: Latest news

  • Updates from each org on the call - 2U, Edunext, OpenCraft, Raccoon Gang
  • 2U:
    • Felipe Montoya : Update from Jeremy Ristau at 2U - they’ve been seeking a volunteer who’d be interested in joining this meeting regularly but didn’t yet have anyone step forward.
  • OpenCraft:
  • Edunext:
    • MoisĂ©s González spent a little bit of time researching the new course search feature and testing it out on a large instance. However, encountered a problem: with ~43,000 courses on the instance, the reindex_studio command crashes before it even starts indexing.
      • Maksim Sokolskiy is also interested to know what happens with one very large course, because he experienced a failure when trying to do this with ElasticSearch.
      • Braden MacDonald to follow up with MoisĂ©s González to modify the command to better support instances with large numbers of courses.
  • Jhony Avella worked on upgrading to Kubernetes 1.29. So far haven’t had any issues.
    • Maksim Sokolskiy mentioned that the issue they had with the similar upgrade was related to Bottlerocket images.
  • Jhony Avella is hoping people interested in Horizontal Pod Autoscaling can comment on this discussion thread.
  • Felipe Montoya In anticipation of Aspects, we have started saving logs on our instances that will want to use it, so that when Aspects is officially installed/enabled, there will be existing data to populate it.
  • Raccoon Gang:
    • Maksim Sokolskiy We are experimenting with testing Aspects with single installations. Today I encountered a huge performance issue caused by docker logs. If anyone else is using Aspects on non-Kubernetes installations, they may encounter this. We were testing an instance with a huge number of users (1 million) and this caused the instance to utilize all available resources (e.g. cpus) just to work with this amount of logs. The problem was that all stdout data was stored in docker’s store, and the dockerd simply cannot work with that huge volume of stored data. The solution was to clear the docker store of logs. (Aspects was still fine because the log data was sent to clickhouse separately.)
      • Cristhian Garcia : Once Aspects is enabled it can be very verbose with xAPI statements (which go to stdout by default, making this issue much worse). You can reduce it by disabling Caliper and xAPI logging. However, this prevents processing xAPI logs using Vector, so you would need to enable Ralph. The setting are: XAPI_EVENT_LOGGING_ENABLED and CALIPER_EVENT_LOGGING_ENABLED
      • Felipe Montoya We should update the Aspects documentation to mention this potential issue.
      • Does anyone know if there is some built in setting for docker to do log rotation automatically?
        • MoisĂ©s González : yes, you can configure dockerd to do log rotation depending on size or time. In the case of Tutor, by default it actually puts the logs in a directory inside the container. So if the container lives for a long period of time, this directory keeps growing until k8s deletes the pod. (Though in tutor local, it’s a mounted folder that can grow indefinitely)

:memo: Meeting notes

1.10. Marketing Working Group

Chair: Eden Huthmacher

:paperclip: Latest news

:memo: Meeting notes

1.11. Maintainers

Chair: Feanil

  • Tracking Work in Progress Specific to edx-platform:
  • DEPR
  • Create arch-bom tickets for 2U specific DEPR follow-up · Issue #612 · edx/edx-arch-experiments
  • What we have
    • full maintenance board
      • not clear what’s in flight, who’s leading
      • idea: without a clear leader, tickets should remain way on the left
    • depr board
  • Problem
  • No clear place to track edx-platform specific maintenance work
    • We need prioritization, esp for people who are closely following master
      • Also: the general (not edx-platform) version of this problem
        • do we need an edx-platform-specific solution? or is edx-platfom big enough that it becomes the general problem?
    • We have 3 phase to the maintenance work that we could be thinking about.
      1. DEPR and Upgrade Planning Ticket to declare the work should be done.
      2. Ticket/PR to actually do the work.
      3. Provider/Operator need to react to those breaking changes.
        • master vs named release
    • How we did it for Py38->311
      1. Big upgrade ticket for Py38->311
      2. Big ticket had task list for packages and services, nested task lists
        • Some sub-tickets still open since they weren’t prioritized
      3. Reacting
        1. 2u → No tickets on the maintenance board
        2. Tutor → tracked this with tickets separately
    • Wait, maybe it’s 4 steps:
      1. Plan (announce Py38->311 , make an epic)
      2. Expand (add Py11 support)
      3. React (operators switch to Py11)
      4. Contract (remove Py38 support)
    • Some things benefit from expand-contract, others don’t so much
    • Perhaps we only care about this for changes that impact infrastructure or interfaces.

:memo: Meeting notes

1.12. Product Working Group

Chair: Jenna Makowski

:paperclip: Latest news

  • UX/UI Working Group
    • Database of UX/UI Projects
    • Looking for reviewers for the Graded Discussions Product Proposal :slight_smile:
    • Sam Daitzman presented the latest UI designs for the Open edX mobile project, including both the dark and light mode versions :heart_eyes:
    • We briefly discussed whether the mobile and desktop UX/UI decisions should be consolidated, agreeing that at some stage they probably should
    • We chatted about the option of enhancing / extending / improving the Open edX version of Paragon separately to the edX version. We would need to determine whether the design system should remain general, or if it could become more learning focussed
    • Jenna Makowski ran through the most recent frames for the Libraries Relaunch project. She took us through the flows for creating library content, as well as using it within a course.
  • LTI/Learning Tool WG Meeting
    • We kindly ask participants and anyone interested to watch the following two videos showcasing the prototype aimed at enhancing the administration and reuse of LTI tools. Please share your comments, questions, and feedback in the comments bellow to be addressed in our upcoming meeting.

:memo: Meeting notes

1.13. Security Working Group

Chair: Feanil Patel

:arrow_down: Past meeting notes 2023-07-26 Security WG Meeting

:memo: Meeting notes

1.14. TOC

Chair: Ed Zarecor

:arrow_down: Past meeting notes Open edX Meetup - 2024-02-29 - Panel Discussion

  • Potential grant project for the Open edX project:
    • A proposal was submitted for a sub-award on an NSF grant supporting educational research This continued a discussion from the last meeting. The scope of work was discussed, the grant would be to improve research analytics, and could benefit Open edX in improving both research and API coverage. The proposal aimed to present content to learners in a way that would allow researchers to influence how it was presented
    • There were concerns about ensuring these changes do not interfere with other ongoing efforts and Axim’s workload. The importance of building generic platform capabilities that can be used with other experimental programs beyond the grant project itself was stressed, to make the grant worthwhile even if the project itself doesn’t gain traction to mitigate potential issues, some members suggested setting up institutional “forcing functions” to ensure that any specific integrations did not leak into the core platform, for example by ensuring the providers selected to work on the core and on the non-core features are different teams.
    • The project with Spanish universities was discussed, focusing on integrating new functionalities in the platform and aligning with the community. It was concluded that ways of working could be adapted and a campus working group coordinated.
    • For the next meeting, the goal is to present more detailed documents for this project
  • Converting the discussion service from Ruby to Python:
    • The group discussed the proposal to rewrite a portion of Open edX’s forum codebase. Currently, the service is implemented in Ruby and utilizes MongoDB for data storage – both technologies that are not widely used or familiar within the broader open edX community. The proposed change involves translating the current code from Ruby into Python and migrating data models from MongoDB to MySQL. This would simplify the stack, potentially making it more accessible for developers to contribute improvements.
    • The forum proposal was discussed in detail. The group discussed whether a discussion forum should be built and maintained by the Open edX project or whether integration with third-party solutions should be preferred. Having a robust, open source solution remains a priority in either event. A recommendation was not made at this meeting.
    • The proposal for migrating the forums includes a progressive rollout plan to support large installations, especially organizations like 2U. The question was raised whether the complexity introduced by this approach created enough value to justify that complexity. Conversations with stakeholders will happen between now and the next meeting.
    • While most agreed on its technical benefits, questions arose around prioritization among various projects as well as funding sources for such an undertaking.
    • A document was suggested to recap all the projects and changes currently being discussed in the different working groups and the vision behind it. This was seen as beneficial not just for the TOC, but also for the broader community.
  • Proposal to make course content easily installable on any Open edX instance:
    • The idea was discussed: the content should be easily shared, allowing people to easily contribute to it.
    • It was suggested to add syndication features to existing courses already licensed under creative commons, to allow sharing between instances. A “cartridge” feature was also mentioned, for turning Xcode courses into importable content on other Open edX instances.
    • The importance of designing content for reusability and modularity, rather than creating a single, long course, was emphasized. It is unlikely that individual institutions or companies will invest in such a library due to its public good nature, making it an ideal funding opportunity for organizations like Axim.
    • The conversation concluded with the idea that all content should be decomposable into constituent pieces, allowing people to choose how they want to export it. Due to time, further discussion of this topic was postponed.

:pushpin: Relevant links

:memo: Meeting notes

1.15. Translation Working Group

Chair: Eden Huthmacher

:arrow_down: Past meeting notes 2024-05-15 Translation WG Meeting notes

:memo: Meeting notes

2. Events

  • We are excited to announce the 2024 Open edX conference! The conference will be held at Stellenbosch University in Cape Town, South Africa and will take place between July 2nd and July 5th, 2024. Register here to secure your seat!
  • 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 June 11th - Join the meetup here!
  • Friday June 21st - 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.


Core Contributor Check-in: May 25th - Jun 7th , 2024

:stopwatch: Core Contributor Hours

There was a total of 238 hours of contributions reported this past sprint. This is 35 hours more than the previous sprint of 203 hours.

The overall checklist response rate was 41% for this sprint.

:notebook_with_decorative_cover: Summary of Responses

1. Do you need any help? Or is there anything you’d like to collaborate on?


  • Needs support with documentation errors in the forums

2. What should we improve? Are there any blockers?


3. What did you accomplish this sprint?


  • We came very close to finishing all the tests for Redwood



  • Coordinated with devs for Redwood Release Testing


  • Investigated options for improving XBlock rendering APIs



  • Created PRs for bringing unmaintained Priority 1 repos to include some basic maintenance, like having catalog-info.yml, or having python upgrade workflow. Have listed them here Un-maintained repos info - Google Sheets


  • Worked on creating a media server for serving static assets for learning core content (for use in the new content libraries experience), implementing this ADR
  • Various PR reviews for Redwood fixes



  • Worked on documentation (mostly troubleshooting errors)

4. What do you plan to work on in the upcoming sprint?


  • Finish #222
  • Conference talk


  • Redwood releases!


  • Finish the work on Priority 2 repos


  • More work on the media server

5. What went well this sprint?


  • Everyone is doing a really great job with Redwood. I know it’s hard work and I appreciate all of you!


  • Good coordination on finishing up the tests, identifying issues in the release and getting them fixed


  • Was great to have a sandbox for the Redwood testing. Thanks Edly!


  • Good support from community!

:speech_balloon: Questions or comments?

Please add any questions or comments you might have below. We’d love to hear from you!

And if you’d like to take a peek at the full report, see it on Listaflow

1 Like

@john_curricume Do you have link(s) or details about what you need on this? I am not sure which documentation errors you are referring to.