Set up process for maintenance of o3de.org CODEOWNERS during stabilization/release

[sptramer]

As a consequence of accepting o3de/sig-docs-community#61, we need to put processes in place during stabilization for docs to remember to update the CODEOWNERS appropriately, so that we exercise control over stabilization in an appropriate way. Part of this will be giving sig-release permissions to merge during the stabilization period (see o3de/sig-docs-community#61 (comment)), and then removing all permissions for non-chairs of sig-docs-community to update locked versions of content (including release notes.)

[tonybalandiuk]

@vincent6767 FYI
@sptramer and @chanmosq - in the RFC it was mentioned "We also need a designated review/merge process for the content/docs/release-notes" . Will that be created under this issue or is this issue just limited to a process to update CODEOWNERS?

[sptramer]

This is a limited process for CODEOWNERS maintenance. What we can do to start is have the review/merge process for release notes work as before (combined review of docs and sig-release) - there is a lot of lead time before the next release to work out the exact process. I will file another issue on sig-release for establishing the ownership/review there, for y'all to work out with sig-docs-community at a more convenient time.

[chanmosq]

Clarifying some of the points here. This issue is about:

• Who should be involved in merging to the stabilization branch? Is it just maintainers? Because stabilization should be bugfix only, there should be more restriction. Perhaps only maintainers are the only ones maintaining the integrity of the release.
• Talk to folks from the code side, how are they doing their stabilization process?

Alternative solution for this issue:
Instead of setting up codeowners file specifically for stabilization. Wee can set up branch protection rules.

[vincent6767]

Based on this document, it's only the maintainer on each SIG: https://github.com/o3de/sig-release/blob/main/releases/Process/Stabilization%20Process.md#roles-and-responsibilities
CC: @tonybalandiuk

[chanmosq]

The stabilization process that @vincent6767 linked, which is for the code (o3de) repo is a good model. I think o3de.org repo can follow suit, so that sig-docs-community-maintainers are responsible for merging the stabilization branch into the o3de.org repo. However, it's good to have a backup in case a member of the SIG is unable to fulfill this responsibility. Therefore I think sig-release or the broader maintainers team should also have permission to merge stabilization, which is a setting to adjust in the branch protection rules.

[chanmosq]

@tonybalandiuk @vincent6767 What are your thoughts on amending this document to specify code stabilization and docs stabilization? (Doc: https://github.com/o3de/sig-release/blob/main/releases/Process/Stabilization%20Process.md)
I can help with writing the docs stabilization process.

[vincent6767]

Therefore I think sig-release or the broader maintainers team should also have permission to merge stabilization, which is a setting to adjust in the branch protection rules.

Is it not the case already? I see this is defined in the stabilization document. I might be missing context though.

[chanmosq]

@vincent6767 The process defined is specifically for code-contributing SIGs, those who work on the o3de repo. Separately, SIG Docs & Community (docs-contributing sig) works on the o3de.org repo. We manage our branches separately.
You have a good point about how the guidelines are very similar. However, due to some nuances we need to write separate ones for o3de.org repo's stabilization process.

[vincent6767]

I see. I was thinking the SIG docs community part of the code contributing SIG. I don't see any concern about

1. adding the docs stabilization process in the release process docs
2. having SIG release as a backup to merge the stabilization branch in the event the SIG docs community is unable to fulfill the responsibility.

Waiting for @tonybalandiuk 's comment.

[chanmosq]

1. The docs stabilization is now a part of the release process docs https://github.com/o3de/sig-release/pull/149/files
2. All folks with maintainer role can merge the stabilization branch.

As such, I believe this is now complete.