Note on conventional commits: We’ve tried to use just this to find operator impact but it’s been insufficient to find all the operator impact that is worth documenting in the release notes.
Potentially we could improve this but currently they don’t work.
Feedback from Maintenance Working group:
On conventional commits:
Lot’s of time we’re forced to use feat because we lack another option for a change that is minor but technically not a refactor or other commit type.
What’s the next release?
Next Release: Teak cut on April 9th
Release notes author could look at the change set on a monthly basis.
We should remind everyone use the Next release wiki page for issues that have operational impact.
Having a long-term sandbox that might break and then we figure out why and document that in the release notes if it is in fact operational impact.
[Sarina] If an operator goes to make an update and run into an issue and breaks their instance then we have failed them.
Nuance: If you are running in the happy-path mode of minimal change and toggling feature flags, the upgrade should be smooth.
How can we push for more automation in the release notes?
eg. Toggles have this so we can get a list of the toggles at any point and diff between two points. But currently we don’t have this for frontend plugin slots.
This slots thing is probably a frontend-wg ask.
Other things might have owners in other working groups.
Metrics of Maintenance Health we should start thinking about
Skip to next time.
Action items
Add action items to close the loop on open questions or discussion topics:
Decisions
Type /decision to record the decisions you make in this meeting: