Highlights & Wins (Documented for the Playbook)
I. Context, data, and highlights 📈
Teak.1 master branch was cut on June 26, about 3 weeks later than planned.
We reached 96.9% test completion , largely thanks to the test-a-thons.
The branch cut was delayed slightly to land some last-minute PRs.
II. Successes and achievements 🏅
Community stepped up big time to help with triage and testing.
Async check-ins surfaced blockers early without needing more meetings.
BTR-labeled issues helped bring new contributors into the process.
Test-a-thons drove completion, even if the last one had lower turnout.
Issue transfer flow (BTR ➝ maintainers) made collaboration smoother.
III. We should keep ✅
Toggle automation for waffle flag tracking (huge improvement!)
Test-a-thons as structured checkpoints to boost coverage
Async check-ins before release cut
BTR onboarding using well-labeled issues
Issue flow : moving failures to source repos to increase visibility
📝 We’ll skip live discussion here, but this section will be documented and carried over to future release planning.
What Should We Do Differently? ❌
What We Want to Improve Testing Process and Spreadsheet Add a column in the test spreadsheet to indicate if a test requires technical knowledge (e.g., developer or operator).
Make setup instructions easier to follow by linking to http://openedx.org
Indicate which tests are related to each other, so testers can run several once they’ve done the setup.
Improve test case ID generation:
Don’t delete deprecated tests. Mark them clearly (e.g., using strikethrough or color).
Add a warning or tip about using views instead of filters in the spreadsheet, so people don’t accidentally hide tests.
Encourage contributors to write their own tests using the guides already available in the BTR wiki.
Documentation Continue linking tests to the proper http://openedx.org
Improve those docs where needed—make sure they explain required permissions, where to click, and what to expect.
Avoid duplicating instructions in the spreadsheet. Just link to the docs.
Post-Release Tasks Bug Triage and Issue Management Focus on fixing high-priority issues during the 0.1, 0.2, and 0.3 patch releases.
Community members and maintainers can help with medium and low priority issues.
Keep transferred issues visible on the BTR board so we can track if they reappear across releases.
Avoid deleting duplicate issues that show up in multiple releases—this helps us know if a bug has gone unresolved for a long time.
Before closing an issue, reach out to the person assigned to it to confirm it’s still active.
Frontend Capacity Many of the current issues are in authoring MFEs, but the bug triage team is mostly backend-focused.
We need more frontend contributors, or we should involve frontend folks in the triage process.
Open Questions and Ongoing Discussions
Tools for Managing the Testing Process The test spreadsheet works well for many testers, especially those who aren’t technical.
Still, some tasks (like test creation and issue tracking) might be easier in GitHub or with light automation.
One idea is to explore ways to sync metadata between GitHub and the test sheet—without replacing the spreadsheet entirely.
Keeping Test Cases Up to Date Any product change can affect multiple tests, but we don’t currently track this well.
One idea is to have the product liaison ask contributors what parts of the platform they changed, so we can check if related tests need to be updated.
This process needs more thought: who owns it, how it would work, and how much effort it takes.
Feedback from Users on Older Releases Some people are stuck on old versions of Open edX because of bugs or missing features.
We could reach out to those users to ask what’s blocking them.
This could help us identify missing tests or things we should cover better in the future.
Reviewing Past Retrospective Items There are still open issues from past retrospectives (like Redwood and Sumac).
These should be reviewed before we add new action items from this cycle.
We may need to close or reassign old items that are no longer relevant.
Board Maintenance and Workflow The BTR issue board keeps growing and is harder to manage.
Suggestions included:
Contacting assignees of old issues to see if they’re still planning to work on them.
Asking for a timeline or commitment. If none, close or reassign the issue.
The test failure board is also getting harder to manage. There’s no clear strategy for reviewing and prioritizing those items across releases.
Maria will bring this up at the Maintainers Working Group this week.
The team agreed to set up a working session before the next BTR meeting to clean up the board and follow up on open issues.
Role Clarity and Tagging Roles for the next release are still being finalized.
Amir Aoub is expected to take over as product liaison.
Antonella will likely stay on as testing coordinator.
For now:
Contributor Experience GitHub is still intimidating for some testers.
There are instructions on how to report issues or open pull requests, but we’re not sure how helpful they are to new testers.
We should follow up with testers from the last cycle to ask how the tools worked for them, and what could be improved.
Next Steps
@Maria Grimaldi
Schedule a short working session before the next BTR meeting to:
Review and clean up unresolved items from past retrospectives.
Confirm who will take each role in the next cycle.
Turn action items from this meeting into GitHub issues.
Reach out to recent testers and people using older releases to get feedback on blockers, workflows, and documentation.
Bring the test failure board topic to the Maintainers Working Group and discuss how it should be handled long-term.
Think about how to continue improving the http://openedx.org