Some possible steps to simplify the release process, based on observations while releasing v0.90.0.

core release

• Should step 1 just suggest that the PR is merged? Does keeping it open actually help? If we suggest to just merge, then a separate make update-otel can become step 1 of releasing contrib.
• The PR in step 3 should be created before the issue in step 3. This would allow the first checkbox to be linked directly to the PR.
• Consider splitting step 3 into two steps, since it requires two actions. Step "3a" is to run the workflow, "3b" is to merge the PR. (I'm using 3a and 3b as temporary names to disambiguate from current steps 3 and 4. If implemented, we would number these normally.)
• Merging the PR from step 3 could automatically trigger the work currently described in steps 4 & 5. If this is implemented, then the issue created in step 3 does not need to list the second checkbox, currently described as "Tag and release core v1.0.0/v0.90.0". Additionally, step 6 could be combined into step "3b" since it just describes expectations from merging the PR.
• The issue created in step 3 should include a checkbox for updating the release with changelog. Better would be to automate this as well.
• As noted above, if step 1 just suggested to merge the PR, then step 8 can become step 1 of releasing contrib. Even better, just automatically create this PR once the core release is created.

contrib release

WIP