From 34532588c62aa23f2ce044122c11809b71d54e43 Mon Sep 17 00:00:00 2001
From: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Date: Wed, 5 Aug 2026 13:34:00 -0400
Subject: [PATCH] Update community PR review process (#50601)

---
 handbook/engineering/README.md | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/handbook/engineering/README.md b/handbook/engineering/README.md
index af747a7b53..699deef448 100644
--- a/handbook/engineering/README.md
+++ b/handbook/engineering/README.md
@@ -124,10 +124,6 @@ Because of this shift, the review effort for any change is the same regardless o
 
 The goal is to not go more than one business day without responding to the contributor and routing the PR to the right team. This applies to PRs from Fleeties, open source contributors, members of the Customer Success team, etc.
 
-If the PR is a bug fix that the author has not validated manually, close the PR. Notify the author that the PR will be re-opened and reviewed after they validate the fix.
-
-Make sure to create a Github issue and link it to the PR so that we can track the changes in our release process. Make sure to assign the correct milestone to the issue (by having an issue, QA will make sure the fix is not causing regressions).
-
 1. **On-call triage**: All community PRs are first reviewed by the on-call engineer, who routes the PR to the appropriate product group's EM. Internal Fleeties who already know the owning team can go directly to the EM.
 
 2. **Classification** (EM): The Engineering Manager (EM) of the owning product group determines what type of change this is: bug fix, reliability improvement, product change, or something else.