Merge pull request #251 from o3de/Ulrick28-patch-3

Update O3DE Exception Checklist.md

releases/Process/O3DE Exception Checklist.md

@@ -1,12 +1,9 @@
 **Exception Tracking**
 - [ ] 1. Owning SIG requests the exception, by a Sig Representative (Chair/co-chair) adding the PR to the exception requests queue board.
 - [ ] 2. Owning SIG comments on the PR explaining impact if this code does not go into stabilization.
-- [ ] 3. Unrelated SIG representative (chair/cochair) approves the exception, adding a comment indicating approval and the SIG they represent.
-- [ ] 4. UX SIG representative (chair/cochair) approves the exception, adding a comment indicating approval and the SIG they represent.
-- [ ] 5. Testing SIG representative (chair/cochair) approves the exception, adding a comment indicating approval and the SIG they represent.
-- [ ] (Must occur at some point before SIG-Release approval) Code has been approved for merging by maintainers
-- [ ] 6. SIG-Release Release Manager or co-Release Manager approves the exception, adding a comment indicating approval and the SIG they represent.
-- [ ] 7. If all approvals are accepted, then the exception PR may be merged
-- [ ] 8. Merged PR is verified successful via testing. If Merged PR verification testing failed, consult reps from step 3-5 and discussion occurs on fixing the failure vs backing out change
-- [ ] 9. Update release documentation if needed. You might need to do this if your change affects something that was specifically called out in the release documentaiton. If your exception is early in the stabilization process then, if needed, issue a pull request against the Feature List (sig-release/releases/YY.MM.N/YYMMN.feature list.md , example (/o3de/sig-release/blob/main/releases/23.05.0/23050%20feature%20list.md ). If the release has progressed to the point where release notes are created, then please issue a pull request against the Release Notes  (o3de/o3de.org/content/docs/release-notes/YYMM-release-notes.md) where YYMM is the year and month of the release, for example (o3de/o3de.org/content/docs/release-notes/2305-release-notes.md)
-- [ ] 10. Exception is complete
+- [ ] 3. (Must occur at some point before SIG-Release approval) Code has been approved for merging by maintainers
+- [ ] 4. SIG-Release Release Manager or co-Release Manager approves the exception, adding a comment indicating approval and the SIG they represent.
+- [ ] 5. If all approvals are accepted, then the exception PR may be merged
+- [ ] 6. Merged PR is verified successful via testing. If Merged PR verification testing failed, consult reps from step 3-5 and discussion occurs on fixing the failure vs backing out change
+- [ ] 7. Update release documentation if needed. You might need to do this if your change affects something that was specifically called out in the release documentaiton. If your exception is early in the stabilization process then, if needed, issue a pull request against the Feature List (sig-release/releases/YY.MM.N/YYMMN.feature list.md , example (/o3de/sig-release/blob/main/releases/23.05.0/23050%20feature%20list.md ). If the release has progressed to the point where release notes are created, then please issue a pull request against the Release Notes  (o3de/o3de.org/content/docs/release-notes/YYMM-release-notes.md) where YYMM is the year and month of the release, for example (o3de/o3de.org/content/docs/release-notes/2305-release-notes.md)
+- [ ] 8. Exception is complete