sig-docs-community/governance/sig-triage.md

sig-docs-community triage

Unlike many SIGs, sig-docs-community is "crosscutting" (a stakeholder SIG in almost every other SIG's work) and our triage is slightly different from other groups' as a result. In particular, sig-docs-community triage needs to meet the following criteria at minimum:

• Triage of issues in o3de/o3de.org which have not yet gone through a triage process
• Triage of issues in o3de/o3de which are assigned a sig/docs-community label.

Current triage process

1. Check issues on o3de/o3de.org with the needs-triage label. (Link)
   1. If the issue relates to website development only, add the kind/website label and move to the next triage item. sig-docs-community does not triage website items in this meeting; Website triage must be a separate process to work with vendors or other funded website development.
   2. Discuss in SIG triage to see if the issue is valid, should be rejected, or needs more info.
   3. Assign labels to the issue. Normally you should assign at least one of:
      • feature/
      • kind/
   4. Assign a triage/ label. We have a variety, but the most common will be triage/accepted, triage/needs-more-info and triage/declined. Issues which are declined should be closed, and if need to be handled by another SIG, a corresponding issue should be opened where appropriate (Example of declined issue)
   5. Assign a priority/ label to the item. Priorities of critical and blocker should only be used for high-impact issues that need to either be urgently addressed on the live website, or in an upcoming major release.
   6. Remove the needs-triage label.
2. Check issues on o3de/o3de with the sig/docs-community label. (Link)
   

Most issues which come to sig-docs-community via the o3de repo have already been triaged by an engineering SIG. During cross-SIG triage (or under some individual SIG discretion) the sig/docs-community label is applied to issues where docs would be a stakeholder. For these tickets, it should be enough to leave a comment and, if necessary, create a corresponding issue on o3de/o3de.org.

Check O3DE PRs

While PRs should not be assigned in triage, the SIG should be aware of PR activity on o3de/o3de which may require review from a sig-docs-community reviewer or maintainer. Look through issues on o3de/o3de in pull request which require validation from docs. (Link)

These issues are rare, but do show up! When they do, they tend to go unnoticed by the SIG due to lack of cross-communication, so it's useful to check during triage/PR assignment to see if there are any open PRs on o3de which require docs signoff. Some situations where docs may need to be involved are:

• Tooltip text
• Error messages
• Links to the website
• README or other supplemental information