...
Releasing release notes together with the release.
Shipping on the planned day, even if it requires making touch tough decisions.
Working though these tough decisions by communicating and organizing as a group.
Assigning roles for each release cycle.
Using the GitHub project board (especially with @BbrSofiane’s scrum-mastership).
Using GitHub Actions for edx/configuration CI.
Dates and timing worked much better than in the past, both in terms of how long we had between the cut and the release, and also where the release fell on the calendar. I think the current pacing is ideal.
II. 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?
More and better testing procedures: 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.
Additional group members and/or resources: 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 predict “spending” of core committer time.)
More asynchronous involvement: bi-weekly meetings were introduced in the expectation that more coordination would happen asynchronously (in GH issues, in the forum, etc.). That happened to a significant extent, but it can be improved. (How, though?)
More autonomy: certain tasks/roles require commit rights to certain repositories.
...