From 0d440b7d09b490701f5edf3f0f076bbfdef23afc Mon Sep 17 00:00:00 2001 From: Jeffrey 'Alex' Clark Date: Thu, 9 Apr 2026 18:04:00 -0400 Subject: [PATCH] Trim Plan Maintenance section Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .github/INCIDENT_RESPONSE.md | 30 +----------------------------- 1 file changed, 1 insertion(+), 29 deletions(-) diff --git a/.github/INCIDENT_RESPONSE.md b/.github/INCIDENT_RESPONSE.md index c879e4ed9..029a69028 100644 --- a/.github/INCIDENT_RESPONSE.md +++ b/.github/INCIDENT_RESPONSE.md @@ -221,31 +221,7 @@ After the fix is released and the advisory is public: --- -## 9. Post-Incident Review - -Within **2 weeks** of a Critical or High severity fix being released: - -1. Hold a brief retrospective (async is fine for a distributed team). -2. Document the following metrics for the incident record: - - | Metric | Target | Actual | - |---|---|---| - | Time to acknowledge reporter | ≤ 72 hours | | - | Time to reproduce & assess severity | ≤ 5 days | | - | Time to develop & review fix | Varies by severity | | - | Time from report to public release | Critical ≤ 14 days; High ≤ 30 days | | - -3. Record: - - What went well - - What could be improved - - Root cause: what allowed the vulnerability to exist - - Whether any distro/downstream was impacted before the fix was available -4. File follow-up issues for any process improvements identified. -5. Update this document if the response process needs revision. - ---- - -## 10. Dependency Map +## 9. Dependency Map Understanding what Pillow depends on (upstream) and what depends on Pillow (downstream) is essential for scoping impact and coordinating notifications during an incident. @@ -348,10 +324,6 @@ This document is a living record. It should be kept current so it is useful when incident actually occurs. - **Quarterly review** — revisit during the Section 1.3 readiness review at each quarterly release. -- **Post-incident update** — if the response process revealed gaps or needed improvisation, - update this document before the post-incident review is closed (Section 9). -- **Ownership** — changes are approved by the Core Team and recorded in Git history. - Substantive changes should be noted in the PR description so they are easy to find later. ---