From 7737b3106902a33cac2341eb501118dc7f35ddda Mon Sep 17 00:00:00 2001 From: Sharon Katz <121527325+sharon-fdm@users.noreply.github.com> Date: Wed, 5 Aug 2026 17:13:32 -0400 Subject: [PATCH] Add handbook guidance for code review coverage during time off (#50620) **Related issue:** Closes #49286 # Checklist for submitter If some of the following don't apply, delete the relevant line. - ~Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`.~ N/A (handbook-only change) - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements), JS inline code is prevented especially for url redirects, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - ~Added/updated automated tests~ N/A (handbook-only change) - ~Where appropriate, automated tests simulate multiple hosts and test for host isolation~ N/A - [x] QA'd all new/changed functionality manually For unreleased bug fixes in a release candidate, one of: - ~Confirmed that the fix is not expected to adversely impact load test results~ N/A - ~Alerted the release DRI if additional load testing is needed~ N/A ## Summary Adds a "Code review coverage during time off" section to the Product groups handbook page. When a small product group (2-3 engineers) has someone on vacation, this documents the process: start with AI review, then have the EM find a temporary human reviewer from another group, preferably one the EM also manages. --- handbook/company/product-groups.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/handbook/company/product-groups.md b/handbook/company/product-groups.md index 93266816d0..5b4e78c73b 100644 --- a/handbook/company/product-groups.md +++ b/handbook/company/product-groups.md @@ -196,6 +196,21 @@ Continuous flow does not use story points or track velocity. [T-shirt sizing](#t - **Help finish in-flight work when nothing in Ready is available.** Assist with code review, QA, or sub-issues for active stories. - **Hit a blocker or have a question?** It's okay — blockers happen. Move the issue to **Blocked** and try to resolve it async (in the group's Slack channel, with the relevant collaborator, etc.) rather than waiting for standup. If it isn't resolved async, the next standup is the latest it should go without being addressed. +### Code review coverage during time off + +Fleet's product groups typically have two to three engineers. With AI-assisted development accelerating how fast code is written, deep code review is the primary engineering bottleneck. When one engineer in a small group is on vacation or out of office, the remaining engineer may have no one available to review their pull requests, blocking progress until the teammate returns. + +To prevent PRs from stalling, engineers should arrange temporary review coverage before a teammate's absence (or as soon as the need arises): + +1. **Talk to your Engineering Manager.** Let your EM know you need review coverage. The EM will find an engineer from another product group who can review your PRs while your teammate is out. +2. **Prefer groups under the same Engineering Manager.** When possible, the EM should find a reviewer from another group they also manage. This keeps tracking and follow-up simple since the EM already has visibility into both groups' boards. +3. **Cross-EM arrangements are fine when needed.** If no group under your EM has capacity, the EM can coordinate with another EM to find a reviewer. Both EMs should stay in the loop so the commitment is tracked. +4. **Communicate the plan.** Post in your product group's Slack channel (and the covering group's channel, if different) so everyone knows who is handling reviews and for how long. + +The arrangement between groups can be a mutual trade (your group covers reviews for theirs in return), one-sided help, or whatever works for the teams involved. + +The goal is to keep pull requests moving. A brief async message to arrange coverage is far cheaper than a week of blocked PRs. + ### Daily standup (30 minutes) By-person updates first, then parking lot, then walk the board as time allows. The Inbox is reviewed during standup for bugs and any priority issues (P2 or greater). Complex user stories go through user story review reviewed. It's up to the Product Designer to decide if a user story needs to be reviewed. Simple stories, ones with known patters, can go straigh to the "Ready" column during the next weekly planning.