Guidance needed: Reviewers/maintainers of release notes

[sptramer]

As a consequence of accepting Docs RFC #61 there needs to be a designated reviewer/maintainer group for docs/release-notes. Ideally these reviewer requirements are set by sig-release, and not subject to docs meddling!

Since the next release is quite a while away at this point, this only needs to be addressed before the next stabilization period. At that time there can either be a formal continuation of the current process (docs + sig-release release manager review release notes) or whatever adjustments sig-release would like.

[chanmosq]

We have the appropriate teams:

• sig-release-reviewers
• sig-release-maintainers

We have also added the sig-release-maintainers team to the CODEOWNERS file. This means that when a PR makes changes to these two directories, it automatically assigns sig-docs-community-maintainers and sig-release-maintainers as reviewers of the PR. Either or both teams must review the PR in order to merge it.

# Release content
/content/docs/release-notes/* @o3de/sig-docs-community-maintainers @o3de/sig-release-maintainers
/static/images/release-notes/* @o3de/sig-docs-community-maintainers @o3de/sig-release-maintainers

[sptramer]

Summary for @chanmosq: This is about having a checkpoint of a designated reviewer group (probably sig-maintainers?) who are responsible for signing off on release notes before going live. This would just be part of the release process. Think of it as finding "who the reviewer pool for the release notes" should be.

Suggested timeframe for addressing this (along with other SIG releasing documentation) is for the next release.

[chanmosq]

As @sptramer suggested, I propose pushing forward with a adding to the Major Release Process a "check-point" to validate the contents of the Release Notes, which is curated by the sig-docs-community Documentation Program Manager. The purpose of this validation checkpoint is to ensure that the Release Notes was reviewed before being published. I think the mandatory person to validate should be the sig-release Release Manager, and all other sig-*-reviewers should also be added to the reviewer pool, though are not required.

@tonybalandiuk @vincent6767 thoughts?

Proposed action item for this issue:

• Document a step in the Major Release Process or the old 22.10 Project Release board specific to the Release Manager's review of the release notes. It should happen after the release notes are created,

[vincent6767]

Agree with the proposal above. Let's wait for @tonybalandiuk 's thoughts before proceeding.

[vincent6767]

I propose pushing forward with a adding to the Major Release Process a "check-point" to validate the contents of the Release Notes, which is curated by the sig-docs-community

If we proceed with this proposal, does that mean the SIG Docs community curate / draft the release notes starting from the next release which is 2 - 3 months away? @chanmosq

[chanmosq]

Yes that's right. The responsibilities for sig-docs-community Docs Project Manager remain the same:

Responsible for managing the documentation repository for a release. This includes managing release notes, publishing the documentation for a release, and applying release tags to the docs site. The Documentation Project Manager works closely with the Release manager.
via (Major Release Process)

[tonybalandiuk]

Proposed action item for this issue:

• Document a step in the Major Release Process or the old 22.10 Project Release board specific to the Release Manager's review of the release notes. It should happen after the release notes are created,

I agree with this. I will make these changes to our process and project board. Please keep this open until I make those changes.

[tonybalandiuk]

Done

1. Release process update at https://github.com/o3de/sig-release/pull/149/files - PR is pending review
2. 23.05 project board now contains this task Release Manager - review Release Notes o3de#15295

[tonybalandiuk]

@chanmosq Is there anything else we needed out of this other than the above 2 actions I've taken?

[chanmosq]

Looks good, thanks @tonybalandiuk !