Proposed RFC: Merge access control and designated ownership of o3de/o3de.org about sig-docs-community

[sptramer]

One question for clarification: In the first part of the RFC, you list a set of representative groups, e.g. sig-dc-documentation and o3df-representatives. How are these group names used in practice? Are they for mailing lists? Access control? I'm not sure what purpose they serve when we have the groups that are mentioned later in the RFC such as o3de/docs-reviewers and o3de/lf.

Access control only; The RFC should have been clearer in the summary as to what those generalized groups map to. Here's the list:

• sig-dc-documentation -> The GitHub groups o3de/docs-reviewers and o3de/docs-maintainers
• o3df-representatives -> Currently o3de/lf; This requires some feedback from the Foundation on whether or not they require a different GitHub group for tighter access control on the website.
• sig-dc-community -> o3de/community-reviewers and o3de/community-maintainers, managers of the community-focused content. These groups would almost certainly need permissions on https://github.com/o3de/community as well.
• o3de-website -> o3de/website-reviewers and o3de/website-maintainers, new groups specifically for the website maintenance.

[willihay]

I've read and support this proposal.

One question for clarification: In the first part of the RFC, you list a set of representative groups, e.g. sig-dc-documentation and o3df-representatives. How are these group names used in practice? Are they for mailing lists? Access control? I'm not sure what purpose they serve when we have the groups that are mentioned later in the RFC such as o3de/docs-reviewers and o3de/lf.

[chanmosq]

I've read and support this proposal as well.

[chanmosq]

Upon acceptance, this RFC should also involve updating the SIG Docs and Community Charter to accurately distinguish sig-docs-community's responsibilities. Who's responsible for what parts of the website can easily get fuzzy, so the charter should clarify that.

[chanmosq]

On hold, need feedback from Linux Foundation

[sptramer]

Feedback during release: We also need a designated review/merge process for the content/docs/release-notes directory. I'd propose that this be owned strictly by sig-docs-community chairs and a set of representatives from sig-release. In addition, the policy would allow sig-release activity only on stabilization/version branches.

Owners of release notes on stabilization/version branches

• sig-docs-community chairs or a delegated maintainer
• sig-release maintainers, chairs, or release managers (at the discretion of sig-release)

Owners of release notes on all other branches

• sig-docs-community chairs only. Release notes should not be updated outside of a release period under the current release policies.

Enforcement changes

This means that the CODEOWNERS mechanism will need to be maintained separately on stabilization branches as part of creating them. This would need to become part of an official release process checklist.

cc @o3de/sig-release

[chanmosq]

We'll leave this open for further review one more week. The last day to address this is Friday Oct. 28

[chanmosq]

This RFC has been accepted. Acceptance took place at sig-docs-community meeting on 11/09/2022.

[sptramer]

Action items:

• o3de/o3de.org#2097
• o3de/sig-release#108
• o3de/sig-release#109
• #75
• #76