...
- Step 1. The PO works with her team to investigate the issue. The team determines fix strategy, effort, risk, and a test plan
- Step 2. PO prepares the Jira ticket (see ProcessLogistics and Requestor will present these items in meeting with RMS panel). When the ticket is populated, the PO sends a message to #release_bug_triage channel. The RMS Panel members, who monitor the channel vigilantly, immediately review the provided material. If the case is compelling enough, they issue their approval right away. If the case is so not clear-cut, the Release Coordinator schedules a meeting for the Requestor PO with the RMS Panel members.
- Approvers: D Howell (Support rep), K Martin (PC rep), Y Kumar (QA), L Braginski (Dev), J Skoczen, M Veksler, M Gorrell (CC rep), H Kaplanian, K Gambrell. Need 5 approvals, including 2 technical approvers (Mark V, Lee, Mike G, Jakub)
- Step 3. If the RMS decision is a Go, the appropriate development team is tasked to go ahead with the fix.
- If the decision is a NoGo, then PO will make sure to add a workaround to the JIRA issue and additional details to release notes (see ProcessLogistics)
- Step 4. In the case of a Go, the CSP is released as soon as the work completed
...
- The value in “Release” field is set to <Target release> Service Patch <Number>, e.g. “Orchid (R1 2023) Service Patch #1”
- “RCA” field is populated
- Test cases in TestRail linked
- “CSP Request Details” field is populated (see Requestor will present these items in meeting with RMS pane)
- RMS reviews and provides the disposition on the request in a meeting (see Requestor will present these items in meeting with RMS pane)
- If approved, the Requestor must set the field “CSP Approved” = Yes
- If not approved, the Requestor must set the field “CSP Approved” = No and populate the field “CSP Rejection Details”
...