We should keep:
Releasing release notes together with the release
Shipping on the planned day, even if it means cutting features
Assigning roles for each release cycle
Using the GitHub project board, especially with @BbrSofiane’s scrum-mastership
Using GitHub Actions for edx/configuration CI
Working though hard release management decisions by communicating and organizing as a group
We need to change:
The fact that the process wiki page is too long to be able to use as a checklist. Some tasks were still being discovered after the release! Maybe some way to create GitHub Project tickets for everything up-front?
Testing: we didn’t have clear signals of testing happening, and what the outcomes were.
Sticking to the RC timeline: RC1 should have been tagged much earlier, so that testing could have been better coordinated.
Group participation: the more people and organizations we get involved in the group, the more resources will be available for taking on individual tasks.
Clearer responsibilities and acceptance criteria for each task, including deadlines and, where possible, estimates of the amount of work involved.
A clearer expectation of the amount of involvement required for each of the official roles, based on the experience of the Lilac release cycle. (Could be used as a way to “spend” core committer time.)