Sumac.1 Retrospective 🌳⏪

How to contribute 📝

1️⃣ Review the template and add your thoughts under the relevant sections.
2️⃣ Be specific! Share what worked well, what didn’t, and any actionable suggestions for improvement.
3️⃣ Tag yourself in your contributions (e.g., [Your Name]: Your feedback here).
4️⃣ Keep it constructive. The goal is to learn and refine our process.

Where to focus your feedback 🔎

✅ Successes & achievements – What went well? What should we continue doing?
❌ Challenges & improvements – What issues did we face? How could we handle them better next time?
📈 Action items for Teak – What concrete steps should we take to improve?

Some key areas to consider:

• Product 🏗️

• Testing process 🔍

• Bug triage & fixing 🐛

• Security 🔐

• Backports ⏪

• Release notes 📄

I. Context, data, and highlights 📈

• The Sumac master branch was cut on 10/24, two weeks later than originally planned.

• The testing process was completed to 96.4% and took 7 weeks.

• Due to some deployment issues discovered with MongoDB index creation on 2U Forums v2, the Sumac release was delayed one week and successfully released on 16/12.

II. Successes and achievements 🏅

• Removed or improved some of the older tests.

III. We should keep ✅

• Tight coordination between BTR and PWG, particulary on testing. Thank you @Andrés González and @Chelsea Rathbun [@Peter Pinch]

• regular community release meetings in the run up to the release. [@Peter Pinch]

• Documenting the onboarding process for roles to make knowledge transfer smoother and more sustainable over time. [ @Maria Grimaldi ]

• Discuss high-priority issues in BTR meetings to find potential release blockers. [ @Maria Grimaldi ]

IV. What didn’t we do so well, and what could we have done to do better ❌

Product

• [Hina]: The decision to include the dark theme in Open edX was finalized at the last moment, leaving limited time to address related bugs effectively. Although discussions were ongoing, the late timing of the decision affected the resolution process. To improve, it would be helpful to communicate planning phases and decisions to the community earlier, allowing more time for preparation and issue resolution.

• I’m personally glad that we stretched to accommodate Forums v2, but it still doesn’t seem stable and I don’t know of anyone who has sucessfully migrated an existing installation to it yet. [@Peter Pinch]

Testing

• [Dawoud]: Despite having a sandbox available early on and with a 6-week testing window, the test coverage reached 100% at the very end. The test coverage was slow at the beginning and only when some folks from MIT were back that it sped up. Could the over-reliance on certain individuals be a bottleneck in the testing process? I understand most of the folks are from organizations with a stake in Open edX releases. But having a good/decent enough balance of volunteers can be helpful for next time.

Bug triage and fixing

• We should keep maintainers involved and gradually increase their participation, especially for MFEs since they usually have the most issues during release testing. Engagement was better than Redwood, but there's still the question of whether this should be officially part of the Maintainer's job. The goal isn't for maintainers to fix these issues themselves but to help the BTR team find the right people to handle them. [ @Maria Grimaldi ]

• We should bring back milestones in the repo and prioritize issues during the release cycle, deciding what to tackle for the current and next releases. This will help with planning, keep us more focused during release testing, and make sure we're working on the right things. [ @Maria Grimaldi ]

• What can we do to encourage community members to get involved in resolving issues? Would it help if each BTR member brought a list of priorities to their organizations to find contributors? [ @Maria Grimaldi ]

•  

Security

Release notes

• What’s happened to flag annotations and OEP-19? [@Peter Pinch]

• Do we get anything of value out of conventional commits? [@Peter Pinch]

• The settings/toggles generation is undocumented and not very repeatable, making each release more painful than it should be. We should automate the process to improve reliability and reduce effort. [ @Maria Grimaldi ]

Backports

• There’s still no clear process for efficiently identifying critical backports. As part of the Redwood retrospective, we opened this issue: Backports policy and information radiators · Issue #395 · openedx/wg-build-test-release , but the process I suggested is manual and time-consuming. The goal is to find an easy way to do it manually while keeping it repeatable. [ @Maria Grimaldi ]

VI. Action Items for Teak release 📈

Product

Testing

• In between releases, we should work on cleaning up the testing sheets, adding test instructions or removing outdated tests. [@Peter Pinch]

• It would also be nice to identify any tests that could reasonably be automated.

Bug triage and fixing

• Plan issues to fix for next point releases. [ @Maria Grimaldi ]

• Follow-up tutor-indigo adoption to avoid more issues related to the theme. [ @Maria Grimaldi ]

Security

Backports

• Meet with the release manager and figure out how to manage backports. [ @Maria Grimaldi]

Release notes

• Automate settings/toggles generation for easier extraction. [ @Maria Grimaldi ]