# Fork PR workflow approval: no escalation path when reviewer pings go unanswered **URL:** \ **Category:** Uncategorized\ **Created:** [August 29, 2026, 7:43pm UTC](https://dev-discuss.pytorch.org/t/fork-pr-workflow-approval-no-escalation-path-when-reviewer-pings-go-unanswered/3430 "2026-08-29T19:43:36Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![tolleybot](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/tolleybot/32/3332_2.png) [@tolleybot](https://dev-discuss.pytorch.org/u/tolleybot)\ **Post date:** [August 29, 2026, 7:43pm UTC](https://dev-discuss.pytorch.org/t/fork-pr-workflow-approval-no-escalation-path-when-reviewer-pings-go-unanswered/3430/1 "2026-08-29T19:43:36Z")
Hi all, I’d like to ask about the workflow approval step for fork PRs, specifically what a contributor should do when the documented path does not produce a result. The documented path. When a ciflow label is applied to a fork PR, the bot posts: _Once a maintainer approves the workflows (scroll to the bottom of the PR page), the corresponding CI jobs will be triggered automatically. Please ping one of the reviewers if you do not have access to approve and run workflows._ So the process has one step: ping a reviewer. The contribution guide does not cover this case, and I have not found a documented fallback for when that ping goes unanswered. Where that leaves three of my PRs. All are open, all are mergeable, and none has ever run CI: - #176434 (export.load deserialization moved to C++), opened March 4. Eight comments from me over that period. Two checks have ever run, both trivial. Has ciflow/inductor, still awaiting workflow approval. - #177985 (SDPA memory-efficient attention crash at num\_heads \>= 65536), opened March 20. Four pings. Three checks. No ciflow label was ever applied. - #195100 (thread safety in torch.export.load), opened August 28. Has ciflow/inductor, awaiting approval. I am not raising this about any individual reviewer. Everyone is busy, and an unanswered ping is a normal outcome. The issue is that the process treats a ping as reliable when it is not, and offers nothing after it. A relevant precedent. My PR #175983 sat in exactly this state for about seven weeks. What eventually cleared it was a maintainer running @pytorchbot rebase, which triggered the pending workflows as a side effect. That worked, but it happened incidentally rather than through any documented route, and it is not something a contributor can do for themselves. Questions. 1. Is there a way for a contributor with a merge history to have fork workflows approved without a per-PR ping? I have five merged PRs since October 2024 (#132049, #138964, #172123, #173391, #175983), so the first-time-contributor protection this gate provides no longer seems to apply. 2. Failing that, is there a documented escalation when a ping goes unanswered for an extended period? A triage rotation, a channel, or a bot command would all work. 3. Should ciflow labels be applicable by the PR author once they have merged commits? That would remove one of the two gates without weakening the approval protection. Happy to help with documentation on this if it would be useful, since the current behaviour is not described anywhere I could find. Don (@tolleybot) ---
**Author:** ![tolleybot](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/tolleybot/32/3332_2.png) [@tolleybot](https://dev-discuss.pytorch.org/u/tolleybot)\ **Post date:** [October 3, 2026, 4:21am UTC](https://dev-discuss.pytorch.org/t/fork-pr-workflow-approval-no-escalation-path-when-reviewer-pings-go-unanswered/3430/2 "2026-10-03T04:21:25Z")
A concrete outcome to add to this thread, since it is the case the original questions were about. #177985 was closed unmerged yesterday after six and a half months and replaced by #199594, which reimplements the same fix. Both target #142228. The timeline is the part relevant here. Opened 20 March. First reviewer response after 48 days, then 38, then 56, then closure after 31. My own turnarounds in between were 1, 7 and 15 days. Over that period the PR received four inline comments and no review verdict: `reviewDecision` was never `APPROVED` and never `CHANGES_REQUESTED`. Worth noting the two roles were separate. The maintainer who reviewed it left four inline comments across two rounds. The maintainer who closed it and opened the replacement had made two comments in six and a half months, neither on the code. It also never ran CI. The mandatory `pull` workflow sat at `action_required` for six months because fork workflow approval was never granted, and I requested it in April, June twice, July and September. When I eventually discovered that `@pytorchbot label “ciflow/pull”` is author-applicable and ran it myself, two real bugs surfaced immediately: silently wrong fp16 and bf16 gradients from non-contiguous head slices, and a grouped-query attention failure above 65,535 query heads introduced by #191085. Both are now covered by tests in the replacement PR. Neither would have been found if the PR had been reviewed and merged early. I am not disputing the technical decision. The replacement takes a better approach, chunking the launch grid rather than the heads, and it is smaller. The questions are about process: 1. **\*\*What signal should a contributor get that a PR is being taken over rather than reviewed?\*\*** I rebased off a six-month-old base and asked for workflow approval seventeen hours before it was closed. There was no indication that was happening. 2. **\*\*Is there a convention for referencing a closed PR when its findings carry into a replacement?\*\*** The two bugs above were found and documented on the closed PR. A line in the description would keep the trail. 3. **\*\*At what point should a PR with no verdict after several months be closed explicitly rather than left open?\*\*** Six months of waiting was worse for everyone than an early “we would rather do this differently.” The underlying issue is getting fixed, which matters more than whose PR does it. But six months of review latency on a PR that could not run CI is the pattern this thread was opened about, and it has now cost one.