Core Contributor Update: Sep 13th - Sep 27th, 2024
Use the jump links below to view the section that interests you:
1. Working Groups Updates
1.1. BTR Working Group
Chair: @jalondonot
Latest news
- Redwood retrospective:
- Thinking ahead: Sumac
sumac.master ~ 2024-10-23
sumac.1 ~ 2024-12-09
- Alignment with the 2024-2025 Community Release Plan and monthly follow-ups led by the Product WG Community Release Planning
- Cutoff and release dates
- We’re considering two options: either 6 weeks before release, on Oct 23, or 7 weeks before release, on Oct 16. The 7-week option is there to account for the week-or-so that it took for the release testing sandbox to come up for Redwood. If Edly can guarantee the testing sandbox can be ready a day before the cutoff, we could aim to a 6-week testing and debugging period.
- Vacant BTR positions
- We agreed on guaranteeing a shadowing period for offering some psychological safety to the new members and ensuring a proper knowledge transfer.
Meeting notes
1.2. Contributor Coordination Working Group
Chair: Jorge Londoño
Past meeting notes 2024-09-03 CC Working Group Meeting Notes
- The meeting focused on Obtain feedback & iterate on core sprint checkins & retros · Issue #95 · openedx/wg-coordination, where Cassie presented a document summarizing feedback from core contributors, focusing on six key areas, and suggested a call for proposals. The team discussed the need for a structured approach to address important topics and measure the impact of the proposed solutions.
- Cassie, Xavier, Jorge, and Ed discussed the planning and execution of a summit. They agreed to set a date for the summit, with the 14th of October being proposed, and decided to allow people to submit proposals, with a deadline set for the week of the 21st of October. The team also discussed the need for a document or proposal format for the summit, with Cassie agreeing to edit the document to clarify that a proposal does not involve funding.
- Ed suggested migrating all meetings to a new tool for automatic recording and easy sharing of videos, and proposed to finalize the details and then transfer the meetings over, suggesting a connection on Friday or the following week. Ed also suggested having a list of co-hosts for the meeting.
1.3. Data Working Group
Chair: @e0d & @blarghmatey
- The Course Comparison Dashboard (currently on a sandbox) will be released with Sumac in December.
- The dashboard allows filtering of courses and course runs using course-level tags. There was a discussion about how tags function on the platform, with documentation available for adding tags at the course level and general content tagging. (Note: Tag filters only work for tags applied at the course level).
- The dashboard lets users compare multiple courses and course runs, with access determined by user permissions in Django. A permissions matrix is available for more details.
- Several improvements will be added to existing dashboards (course, at-risk, and individual learner dashboards) with the Sumac release.
- A demo of the current Course Dashboard is available, and a new demo video covering the Individual and At-Risk Learner Dashboard will be recorded soon.
- Campus IL is looking into xAPI events for Drag and Drop and Open Response Assessments - will follow-up with an update once there is more to report
- Plans for next Data Working Group Meeting - hoping to discuss OEX platform data strategy draft with the community for feedback
1.4. DEPR Working Group
Chair: @feanil
- Discuss DEPR pilot addendums in the linked issue comment: Pilot: Use the DEPR process for breaking changes · Issue #595 · openedx/open-edx-proposals.
- Discuss how to close [DEPR]: Complete removal of EdxRestApiClient · Issue #189 · openedx/public-engineering (see linked comments).
- Review the page MFE Rewrite Tracker and ensure that all the information is as up to date as possible.
- Robert Raposa clean list of accessed legacy frontend views from edx.org / Datadog and use it to supplement the above page.
- Kyle McCormick file a bug for view live on custom-pages studio view
- [inform] Attempt to complete [DEPR]: USE-JWT-COOKIE header · Issue #371 · openedx/edx-drf-extensions did not go as planned.
- There is an updated plan, that may sit for a very long time.
- DEPR of a CORS Allowed header ain’t easy.
1.6. Tutor Users’ Group
Chair: Kyle McCormick
- Improve Tutor’s shell autocompletion response time · Issue #26 · openedx/wg-devops
- AI
- perf: don’t unneccessarily rebuild dev assets by kdmccormick · Pull Request #39 · kdmccormick/tutor
- Kyle will work on this in November
- Database migrations are slow
- An older doc on this: Everything About Database Migrations | Comment
1.7. Educators Working Group
Chair: @john_curricume
1.8. Frontend Working Group
Chair: @arbrandes
- Slot Documentation and Release Notes (Sarina Canelake):
- Sarina proposed improving the release notes for plugin slots, specifically aimed at non-technical decision-makers. She emphasized using screenshots and user-friendly descriptions to show the value of new features.
- The discussion covered providing before-and-after comparisons in screenshots to demonstrate the changes, like how a header or course card could be customized with plugins.
- Sarina clarified that she’s not asking engineers to write release notes but would need clear visual examples to assist her in crafting non-technical documentation.
- Plugin Slot Props and Standards (Adolfo Brandes):
- Adolfo introduced the topic of slot props and clarified that adding props to slots is a non-breaking change. This allows for flexibility and evolution of the slots without breaking previous functionality.
- Jason and Max, who authored a plugin-related PR, discussed how they can meet the technical documentation standards and Sarina’s request for more user-friendly examples.
- Modifications to Plugin Slots (Brian Smith):
- A conversation around how plugin slots are being used in modifying components. The group agreed on the need to ensure plugins do not rely on default content but use provided props.
- The team discussed how plugin props can be merged without explicitly passing them and considered the risks of plugins assuming default content that might change in the future.
- Handling Arbitrary JavaScript in MFEs (Max Frank):
- Max raised the idea of improving how arbitrary JavaScript can be injected into micro frontend environments (MFEs). Currently, a workaround is used by placing scripts in the footer slot, which isn’t ideal.
- He proposed refactoring the external scripts functionality to pull loaders from an
end-config.jsfile, making it more configurable and efficient. There was broad support for this idea, though considerations around performance were also mentioned.- Upcoming Releases and Deadlines:
- The team was reminded of the upcoming Sumac release cutoff on October 23rd. Developers were encouraged to ensure any final features are submitted before that deadline.
- Key Takeaways:
- The group emphasized improving communication and documentation between technical and non-technical stakeholders.
- Slot props were highlighted as a flexible tool that can evolve without causing breaking changes.
- There was an interest in improving how JavaScript is injected into MFEs to accommodate more diverse needs efficiently.
- The next major event will be the Sumac release, with a final cutoff in late October.
- This meeting was productive in addressing both technical and user-facing improvements related to the frontend development workflow.
1.9. Large Instances Working Group
- Internal Hackathon Project and Harmony Works Implementation
Jhony Avella discussed the progress of an internal hackathon project, which involved the implementation of integration tests for their Harmony chart and plugin. He mentioned that the project is still a work in progress and will be reviewed once a more stable version is available. Jhony also shared that they plan to start implementing the Harmony Works technology on their stack in the next few weeks. He mentioned that they are analyzing what is missing to implement this technology and will propose adjustments before proceeding with the migration.- Pod configuration
Jhony also discussed the changes they are making to the configuration of their pods, including the number of workers, HPA settings, and memory limits, to improve performance and prevent errors. The team is using the K6 load testing library to evaluate these changes.- Administrative Details
Felipe Montoya mentioned a potential shift in hosting calls to Google meets and promised to keep Braden and others informed. The team also discussed the recording of their meetings, with Braden noting that he receives an email with the recording link.
1.10. Marketing Working Group
Chair: Eden Huthmacher
- Next Open edX Meetup: UniDigital & Open edX Sandbox Update
- Link to register: Open edX LMS: Transformative Enhancements and Hands-On Exploration
- Engaged Consultant to define revised go to market strategy
- Next conference to attend in early 2025 - 2 proposals:
- BizDev sub-group - weekly update
- OKR Strategy Review in GitHub
- Relevant link: Marketing Working Group • openedx
1.11. Maintainers
Chair: Feanil
- Continued discussion on whether we should change the Depr 6-month window approach. Should we have one big ticket for something like Python 3.8 or Node 18 and just start the 6-month clock once all the maintained repos have been updated?:
- Proposal to shorten the DEPR simultaneous support window to 4-months, for future upgrade DEPRs that need to have a support window/operator impact.
- We chose 6-months to guarantee it would be in one release.
- Alternate Proposal:
- Provide a predictable time when the fix will be gauranteed to be available within the next six months.
- Announce the DEPR as early as possible (6-months is ideal) and at the end of the DEPR, there has to be a 1-month period of simultaneous support.
- The Plan is announced early and the time when the work is completed is as predictable as possible.
- If the work is done early, we should keep the original date but this could be negotiated. Get agreement from people running master.
- If the work is completed late, we provide a 1-month simultaneous support window from the time of completion.
- We give at least six months announcement window. But the work does not need to have started or completed when we make the announcement.
- Celery sharing:
- See feat: run celery without mingle, heartbeat, or gossip by iloveagent57 · Pull Request #68 · edx/configuration
- Régis Behmo Felipe Montoya Jhony Avella flagging as a potential improvement to make to how Tutor or Harmony runs celery.
- I think we’ve proven empirically that the issue is as follows (this is not captured well by our docs yet, so that could cause some confusion w.r.t. state of actual resolution):
- We were running with celery mingle enabled (b/c its enabled by default). Mingle means that, on worker startup (including restarts), each worker asks about the state of every other worker bound to the broker (redis).
- Every edx python IDA that uses celery used a single broker (the legacy redis cluster).
- edxapp was running with 30 worker instances each, and each one of those runs around 14 parent celery worker processes.
- The confluence of these three things kicked off a “connection storm” in redis, causing massive amounts of (duplicated) task data to be sent out over the network to every worker, which caused us to pin the redis engine CPU at 100%, and blocked all workers from processing tasks from any queue.The way we proved this empirically - during deploys (i.e. when we bring up a larger number of new worker processes), look at the following:
- The number of “sync with” celery logs eminating from the celery workers.
- The total network out from redis to the workers.
- Redis engine CPU utilization
- Redis new and current network connection counts.
- In the bad state, all three of these metrics spiked and stayed elevated for quite some time. When mingle was disabled (on stage), none of them spiked.
1.12. Product Working Group
Chair: Jenna Makowski
UX/UI Working Group
1. Overdue Assignment Notifications:
- Current Implementation:
On Web, multiple overdue assignment notifications show separately, even if they belong to the same course (Level 1).- Proposed Grouping Levels:
- Level 2: Group notifications by course. Users receive one notification per course, regardless of how many assignments are overdue.
- Level 3: One notification for all overdue assignments across courses. Tapping the notification leads to a view showing all overdue assignments.
- Mobile vs. Web:
On mobile, users can view all overdue assignments at Level 3, while on Web, routing still needs to be refined. Tapping on Level 2 should lead users to a course’s Dates tab for clarity.2. Migration to Confluence:
- The existing notification tables and documentation in Notion and Figma will be migrated to Confluence for better visibility and input.
- The Confluence database will help catalog metadata for all types of notifications, ensuring alignment and feedback collection.
3. Forum Notifications:
- Forum notifications were the first implementation of the Web notification framework under a separate project. These notifications are categorized as “discussion” in the broader notification system.
- Other notification categories include course dates and grading.
- A second forum-related project is improving course updates, which will require product and UX exploration
LTI/Learning Tool WG Meeting
- Publication of a document explaining at a technical level the development of the first phase of the LTI project: Technical Approach for LTI redesign
1.13. Security Working Group
Chair: Feanil Patel
1.14. TOC
Chair: Ed Zarecor
- Open edX’s Current Market Position and Future Potential
The dialogue opened with concerns about Open edX not achieving a definitive product-market fit which poses a risk to its ecosystem and stakeholders. It was highlighted that expanding the platform’s functionality to cater to residential (on-campus) learning could open new avenues and potentially invigorate its adoption. It would aim to create learning experiences that are more integrated and interactive, providing real-time feedback and support in physical classrooms. However, there was notable deliberation on whether Open edX, in its current architecture, could pivot to meet the demands of residential learning without extensive overhauls or if starting anew with a different product would be more feasible.- Concerns and Alternative Suggestions
Participants expressed concerns about fragmenting the Open edX community with a shift towards a new product. There was also skepticism about whether an entirely new platform was needed or if iterative improvements to Open edX could achieve similar goals. Suggestions were made to further modularize Open edX to allow for easier customization and extension, which could potentially support more interactive and residential learning experiences without starting from scratch.- Funding and Resources
The discussion touched on the need for funding innovative projects that could either extend or complement Open edX to support new forms of learning. It was proposed that small, funded projects could explore innovative educational technologies and tools that could later be integrated into Open edX or stand alone as new products.- Conclusion
The meeting concluded without a consensus on a specific course of action but opened several critical lines of inquiry about the future direction of Open edX. It was agreed that more discussion was necessary, particularly around defining the target customer and market for Open edX and understanding the technical and financial implications of expanding or altering its offerings. The possibility of setting up further discussions or working groups to explore these issues was suggested.- Agreed Next Steps:
- Further Discussions: Organize additional meetings or discussions, possibly involving external experts or stakeholders, to delve deeper into the feasibility and desirability of shifting towards residential learning platforms.
- Market Analysis: Conduct a thorough market analysis to better understand the needs and expectations of potential markets for Open edX, particularly in the residential learning sector.
- Technical Review: Assess the technical capabilities and limitations of Open edX in relation to the proposed new features for residential learning, considering both integration into the existing platform and the development of a new product.
- Community Engagement: Engage more actively with the Open edX community to gather input and feedback on the proposed changes and ensure that any new direction has broad support and meets the needs of current and future users.
1.15. Translation Working Group
Chair: Eden Huthmacher
- Documentation Funding possibility:
- Perhaps Axim would be able to support educator documentation improvements but there are many other segments / groups.
- Documentation Challenges limit Platform growth:
- Many documentation challenges exist, including helping new people to the platform / ecosystem get started. Developers, adopters, educators, etc - lots of different segments and needs.
- Challenges and Roles:
- Documentators Working Group - Initial Document from the last meeting.
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 October 1st - Join the meetup here!
- Friday October 11th - Async update
- Details and draft agenda on Confluence
Anything to add?
If there’s anything else you’d like to mention, please let us know in the comments below.
Core Contributor Hours
Summary of Responses