Maintainer Responsibilities and Release Notes | Adolfo | Issue: It’s hard to write good operator/developer release notes. Concerns: Proposal: Can we get more maintainers involved in helping to write release notes? Not sure exactly how yet. One option: Maintainers flag operational impact issues on Next Release: Teak - Operator/Dev Notes or other documentation location on a per release basis. 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.
Feedback from Maintenance Working group: On conventional commits: What’s the next release? 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. How can we push for more automation in the release notes?
|