The purpose of this doc is to provide guidance on how to manage and run a special interest group (SIG) and manage documentation.

When making edits, please be sure to note your change when you save.

---

A SIG is made up of a SIG chair (or co-chairs) and SIG members.

• Attend SIG meetings and joint TSC/SIG meetings
• Triage incoming issues submitted to o3de.org repo
• Maintain the O3DE roadmap
• Maintain SIG projects

The scope of the SIG and their responsibilities can be found in the charter located at sig-*/governance/charter.md. For example, see Documentation and Community SIG Charter.

Note: SIG chair responsibilities are only partially documented in the charter.

• Meetings. Lead SIG meetings, lead issue triage meetings, and represent their SIG at TSC/SIG meetings.
• Roadmap. SIG chair act as program managers for the SIG’s roadmap. During SIG meetings, they check in with the SIG members’ assigned tasks and update the task’s status. The roadmap should be maintained as the source of truth, which anyone can view to see what’s upcoming for O3DE.

SIG members take on a role as reviewer or maintainer. A maintainer has additional responsibilities and help guide the SIG.

For more information, see Community Membership.

Reference the community calendar

SIG meetings typically occur biweekly or monthly. A SIG meeting provides a space for all SIG members to discuss what’s going on with the SIG and O3DE community as a whole. Some topics include:

• What happened since the last meeting – changes to the team, recent events, O3DE community-wide updates.
• Tasks – open action items and newly resolved items.
• Additional agenda items that members can add.

All SIGs are responsible for triaging issues in:

1. their SIG repo
2. code in the o3de repo, or docs in the o3de.org repo.

If there’s a more appropriate team who can handle the issue, you can transfer the issue to another repo.

Suggestion: Add to “TRIAGE_GUIDE.md” “Proposed SIG-Network meeting agenda” Example: https://github.com/o3de/sig-network/blob/main/TRIAGE_GUIDE.md

The TSC creates a meeting agenda, where the SIG chair from each SIG can provide an update about the SIG. The update can include:

1. what the the SIG has worked on since the last meeting
2. what the SIG plans to work on next.

These updates are generally high-level, pertaining to roadmap items. For example, it’s informative to know what features a SIG is working on, but it’s not necessary to list all the minor issues they resolved.

All SIGs follow the same instructions. See Maintaining O3DE Roadmap.

SIG projects are initiatives that fall into the SIG’s scope as detailed by the charter. They are started by the SIG members or other community members. Typically SIG projects start out as issues and become RFCs (request for comment). SIG RFCs generally follow this format.

All SIGs follow the same instructions. See O3DE Election Guides and Resources.

Instructions on how to become a SIG member can be found in the SIG charter. For example, see To request membership to or update the team in the Maintainers section of the charter.

Maintaining O3DE Docs involves SIG maintainers and reviewers to review and merge pull requests in the o3de.org repository.

Note: In the past, maintainers of the SIG Docs and Community were responsible for reviewing and merging pull requests. Now, maintainers from any SIG have permission to do so.

1. Open the o3de.org repository in the GitHub web interface.
2. In the navigation, open Pull requests (PRs). “Open” PRs contain changes that a contributor would like to make to the documentation.
3. Choose a PR to view its details.
4. In the navigation of the PR, choose Files changed. This lists all proposed changes.
5. Ensure that the docs changes are technically accurate and use a consistent style.
   • For style changes, refer to the O3DE Style Guide. Make suggestions and comments requesting the contributor to make those changes.
   • For technical accuracy, refer to a subject matter expert (SME). While the contributor may be the expert, it’s best to request a review from another expert to double-check their work. Typically, this can be a member from the SIG that this PR pertains to.
6. When you’ve deemed the PR is ready, choose Review changes, select Approve, and choose Submit review.

There are a few key factors to note when merging docs changes:

• A PR can be reviewed/approved by many reviewers, but it must be approved by a code owner of the file.
• A PR is typically merged to either the main or development branch. Only PRs merged to the main branch will appear in the live website.

• One (1) approval from a valid reviewer
• A valid reviewer is someone who’s marked as a code owner for the files updated in this PR. Code owner rules are specified in the CODEOWNERS file of the repo.

Note: Requirements are defined for each branch, via the GitHub branch protection rules and the General settings.

In the PR webpage, at the bottom of the Conversations tab, there’s an action to merge the PR.

Note: A PR is typically merged to either the main or development branch. Only PRs merged to the main branch will appear in the live website. The development branch must be merged to main via the docs release process.

Contributors to O3DE Docs are writers, engineers, and other community members. There is complete documentation about how to contribute in the Contributing Guide.

To continue to support O3DE engineering contributors to also contribute documentation updates for their feature work, we have implemented the following:

• Comprehensive contributor guidelines for O3DE documentation https://www.o3de.org/docs/contributing/
• Simplified PR review requirements. Previously, PRs required 2 approvals from corresponding code owners and had to be merged by a member of sig-docs-community. Now a PR only requires 1 approval, and can be merged by a member of any SIG maintainers team