/
Lilac.1 Release Retrospective

Lilac.1 Release Retrospective

Owned by Former user (Deleted)
Last updated: Jun 21, 2021 by Ned Batchelder (Deactivated)
2 min read

I. We should keep:

  1. Releasing release notes together with the release.

  2. Shipping on the planned day, even if it requires making tough decisions.

  3. Working though these tough decisions by communicating and organizing as a group.

  4. Assigning roles for each release cycle.

  5. Using the GitHub project board and having a specific role for tending it.

  6. Using GitHub Actions for edx/configuration CI.

  7. The current release timeline, with the exception of the third point release coinciding with the cutoff from master.

  8. Documenting stuff.

  9. Having a two-week checkpoint to see what was done in the previous interval.

II. We need to change:

  1. 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?

  2. More and better testing procedures, including what to test: we didn’t have clear signals of testing happening, and what the outcomes were (including when tests were successful).

  3. We should fire up public sandboxes to give non-technical people the ability to test release candidates.

  4. Sticking to the RC timeline: RC1 should have been tagged much earlier, so that testing could have been better coordinated.

  5. 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. Ideas:

    1. Make it clearer how people can participate, even if not necessarily by taking up a role, or coming to meetings, etc.

    2. Post issues on the BTR board and make it clear (via tags?) that they can be taken up by anybody.

  6. Clearer responsibilities and acceptance criteria for each task, including deadlines and, where possible, estimates of the amount of work involved.

    1. Start using issue templates for this.

  7. 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.)

  8. 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?)

    1. Having a ticket reviewer (or a board reviewer) to nag people and share responsibility

  9. More autonomy: certain tasks/roles require commit rights to certain repositories.

  10. Still more work to do on improving, capturing processes (in particular, release notes).

  11. Docker devstack images were overlooked, and I still don’t know how they get created.

Questions:

(These should be moved into one of the keep/change categories above, based on further discussion.)

  1. Are bi-weekly meetings enough?

  2. Should we stick with a 2-month cut-off for maple.master?

  3. Are ADRs a good fit for documenting group decisions? Should the action items on this retrospective make it into an ADR for Maple, for instance?

  4. Are periodic forum updates good? Are they necessary? What form should they take, and under what interval should they be posted?

  5. Should more of the infrastructed be owned, or at least manageable, by the group? Currently the calendar (Gcal), comms (Zoom), and cloud storage (Gdrive) are owned by the chairing organization (Opencraft), making transitions and backups more complicated.

Related content