Page Comparison

...

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

[Jenna]: Redwood was feature-packed. How can we scale back and still have a meaningful set of capabilities/features in Sumac, without over-committing?
[Sarina] how can we “fast fail” in the monthly release meetings run by product (that is, “kick” something out of the release as soon as it’s slipping, and divert resources to getting the other things done)?
[Sarina] consider having release meetings every month, always looking forward to the next release’s cut. Starting meetings in August for an October cut seems a bit late.

[Jenna]: How can we tighten the lead time between the code cutoff and having the testing sandboxes ready? For Redwood, there was about a week in between. How can product help in defining which features should be enabled, etc?
[Jenna]: Only having 3 weeks for testing ended up feeling tight. What what would it look like to try a 6 week testing period between code cut and release, especially if we can shorten the lead time on the sandboxes?
[Chelsea]: We could potentially firm up exactly how the testing sandbox should be configured and make sure that’s communicated well with the team setting up the testing sandbox (Example: it was a miss on my part to make sure Aspects was enabled from the start).
[Peter]: Some of the regression tests are poorly defined and therefore difficult to test confidently. For the next release, we should try to define the legacy tests as well as the new tests were defined.
[Chelsea]: I had claimed/planned to do a test that only once I sat down to do the test did I realize how technical the tester needed to be to test the functionality. It made me wonder if our test sheet should have a designated label for tests that need to be done by an engineer or can be done by anyone.

...

[Peter]: There was a lot uncertainty and confusion with the security issue, particularly around what and with whom details could be discussed. It would be good to have a documented and, ideally, more transparent process before this happens again.
[Maria] We need better documentation to classify security issues and report them effectively.

...

[Jenna]: Redwood was feature-packed. How can we scale back and still have a meaningful set of capabilities/features in Sumac, without over-committing?
[Sarina] how can we “fast fail” in the monthly release meetings run by product (that is, “kick” something out of the release as soon as it’s slipping, and divert resources to getting the other things done)?
[Sarina] consider having release meetings every month, always looking forward to the next release’s cut. Starting meetings in August for an October cut seems a bit late.

[Maria] We need to automatize getting new settings/feature flags/waffles flags for the release notes. I tried it but didn’t have enough capacity to finish the script.

...

[Jenna]: Creating a Gantt chart to track every major project/feature for the next release at a more granular level (epics) instead of at a high level (project) to better assess the risk of whether delivering or not each one of the new features and plan the testing process and required capacity better and in advance.
[Jenna]: Make the Release planning meeting a monthly one and include it in the Community calendar to make sure we start planning every release with enough anticipation.
[Jenna]: Product to update https://docs.google.com/spreadsheets/d/1tWgp9LXNg4sfWYd_0ghNl6qfIZZ9851MtGBXPeSgzFs/edit?gid=0#gid=0 with current plans for Sumac, ahead of the August monthly planning
[Jenna] To discuss: A new role for a product-BTR liaison/coordinator
- To coordinate bug prioritization
- To collaborate with testing manager to write and manage regression and AC tests

[Adolfo]: Continue the conversation about community-supported and always-available sandbox environments.
[Sarina & Adolfo]: Asking the Maintenance WG about the branch cutting and release date.
[Peter]: Review all the tests.
- Remove ones that are no longer relevant.
- Write better test descriptions for legacy tests, in the style of the new Redwood tests.
- Look for opportunities to automate tests.
[Peter]: To discuss: should we invest in the test course repo?
[Maria]: review issues reported on the board with “no test id” or “no test case” to decide whether to include them in the test sheet or specify which test they are part of

[Maria]: Try to solve issues on the board alongside maintainers to avoid accumulating them for Sumac
[Jorge]: Document the communication process, calls for help, and working agreements between the BTR WG and the Maintainers WG to get them more involved and engaged in the Open edX release process.
- Communicate release blockers
[Jenna] To discuss: A new role for a product-BTR liaison/coordinator
- Categorized bugs board
[Adolfo]: Working on an official proposal for automating the sync between the testing spreadsheet and GH.

[Peter]: Confirming and documenting the process for reporting security issues during the release process.