浏览代码

Respond to CR comments, fix SIG captilization, add some extra details

Signed-off-by: Pip Potter <[email protected]>
Pip Potter 3 年之前
父节点
当前提交
7c080280c3
共有 1 个文件被更改,包括 31 次插入27 次删除
  1. 31 27
      TRIAGE_GUIDE.md

+ 31 - 27
TRIAGE_GUIDE.md

@@ -2,59 +2,60 @@
 
 # Overview
 This guide covers triaging issues for SIG-Networking. Maintainers are encouraged to use and update this guide to ensure
-any contributor to sig-network understands how issues are handled.
+any contributor to SIG-Network understands how issues are handled.
 
 
 ##  Issue Triaging
-Triaging is the process of ensuring a smooth intake of issues into sig-network backlog to ensure issues are both relevant to sig-network
+Triaging is the process of ensuring a smooth intake of issues into the SIG-network backlog to ensure issues are both relevant to SIG-Network
 and contain sufficient information so that the community can take action.
 
 Process aims to ensure:
-* The issue is appropriate for sig-network.
+* The issue is appropriate for SIG-Network.
 * The issue has clear information as to the nature of the issue.
 * Issues are regularly maintained and updated until they are resolved.  
 * The issue is an actual issue, rather than a request for help or an issue for another SIG.
 
 
 # Process
-
-sig-network will triage issues once a week on [Thursdays](https://lists.o3de.org/g/o3de-calendar/viewevent?repeatid=39342&eventid=1263668&calstart=2022-01-20). Anyone is welcome to attend. Triage will be led by SIG chair or maintainer.
+SIG-Network will triage issues once a week on [Thursdays](https://lists.o3de.org/g/o3de-calendar/viewevent?repeatid=39342&eventid=1263668&calstart=2022-01-20). Anyone is welcome to attend. Triage will be led by SIG chair or maintainer.
 
 Triaging aims to:
-* Ensure load is balanced across sig maintainers and participants.
-* Involve the sig-network community so all can participate.
+* Ensure issues in backlog are in a ready state for the community to take action upon.
+* Ensure load is balanced across SIG maintainers and participants.
+* Involve the SIG-Network community so all can participate.
 
-If time permits create a new thread in SIG-network and add triage links below.
+If time permits, on the day of triage and before the meeting, create a new thread in SIG-Network and add triage links below.
+* Set the thread to automatically archive after 24 hours.
 
 ## Triage Links
-* Main repro: https://github.com/o3de/o3de/issues?q=is%3Aissue+is%3Aopen+label%3Aneeds-triage+label%3Asig%2Fnetwork 
+* Main O3DE repository: https://github.com/o3de/o3de/issues?q=is%3Aissue+is%3Aopen+label%3Aneeds-triage+label%3Asig%2Fnetwork 
 * Multiplayer Sample: https://github.com/o3de/o3de-multiplayersample/issues
 * NetSoak Test: https://github.com/o3de/o3de-netsoaktest/issues
 
 ## Brief Overview
-1. Join the SIG-network discord voice channel
+1. Join the SIG-Network discord voice channel
 2. Start with main repro link
-3. Process all new issues. New issues in main repro should have labels `needs-triage` and `sig/network`
-   1. Announce issue number and title to those in voice channel
-4. Ensure issue is for sig-network. If the issue is not for sig-network, remove the sig/network` label and comment on the issue. If the correct sig is known 
-    assign it to that SIGm otherwise the general O3DE `needs-triage` meeting will then triage and find the appropriate owners.
+3. Process all new main repository issues. New issues in main repository should have labels `needs-triage` and `sig/network`
+   1. Announce issue number and title to those in Discord voice channel so others can follow along
+4. Ensure issue is for SIG-Network. If the issue is not for SIG-Network, remove the `sig/network` label and comment on the issue. If the correct SIG is known 
+    assign it to that SIG otherwise add the `needs-sig` label so the general O3DE issue triage meeting can triage and find the appropriate owners.
 5. Review the issue and comments and see if it can be accepted
-6. Review the technical implications. If a large change, issue should become an RFC, ask requestor to bring back as RFC.
-7. Assign a reviewer, if required, to handle follow-up comments, repro, questions or comments.
-8. If issue is rejected, assign commenter to reject issue
-9. If issue is accepted, remove `needs-triage` label, set priority for issue and add `triage/accepted`
+6. Review the technical implications. If a large change, issue should become an RFC, ask requestor to bring issue back as RFC or to make a feature request, if that would be more appropriate.
+7. Assign a reviewer, if required, to handle follow-up comments, to reproduce the issue or ask questions.
+8. If issue is rejected, assign commenter to reject issue. 
+9. If issue is accepted, remove `needs-triage` label, set priority for issue and add `triage/accepted` label.
 10. For Multiplayer and NetSoak issues, look for issues less than 14 days old that do not have priorities attached.
-    1. These repros do not have the full set of labels.
+    1. These repositories do not have the full set of labels so some of the process above may not apply directly.
 
 
 If time permits:
-* Review any open and critical issues
+* Review any open [blocker](https://github.com/o3de/o3de/issues?q=is%3Aissue+is%3Aopen+label%3Asig%2Fnetwork+label%3Apriority%2Fblocker) and [critical](is:issue is:open label:sig/network label:priority/critical) issues in the main repository:
   * Ensure priority is still valid
   * Assign any required commentators or ask for updates
-* Review any open `needs-triage` and `needs-sig` issues that may be for sig-network
+* Review any issue open for more than [90 days](is:issue is:open label:sig/network sort:created-asc) and see if its still valid.
+* Review any open `needs-triage` and `needs-sig` issues that may be for SIG-Network
 
 ## Issue Workflow
-
 If you are assigned an issue to validate, work with requestor to get enough information to validate the issue.
 
 If it can be reproduced then:
@@ -77,10 +78,13 @@ Consider adding `help-wanted` for issues that do not have immediate resourcing,
 
 # Stale issues
 
+SIG will periodically audit for stale items. If during triage, you encounter stale issues, use the guidance below to see if issue should be closed.
+
 ## Sig Assigned But No Action
-If an issue with the sig-network label has had no updates for a while (14 days), followup up with the SIG, either through
-Discord chat channel, triage or standard meeting. Consider attending a sig network meeting to raise the issue for discussion.
+If an issue with the SIG-Network label has had no updates for a while (14 days), followup up with the SIG, either through
+Discord chat channel, triage or standard meeting. Consider attending a SIG-Network meeting to raise the issue for discussion.
+
+## No Activity for 90 days
+An issue can be removed if it has been abandoned by the requestor. Issues are considered abandoned if there has been no active for 90 days, esp if issue has had `triage/needs-information` label with no followup from requestor.
 
-## No Activity for 31 days
-An issue can be removed if it has been abandoned by the requestor. If there has been no active for 31 days, issue can be considered abandoned 
-and can be closed out.
+Part of this guide was informed by the [Kubernetes Triage Guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md)