feat(ci): acknowledge new pull requests automatically - #1270
Merged
Conversation
Contributors could not distinguish "blocked" from "ignored". Several PRs sat on green, mergeable work for over a week with no maintainer comment while release-critical work absorbed review capacity, and nothing on the PR page said so. GitHub has no repo-scoped banner for pull requests -- an org announcement banner renders only for org members, and pinned issues and discussions never appear on the PR tab -- so a comment on open is the only surface that reaches an external contributor at the moment they contribute. Posts one comment when a PR is opened, stating that it is queued, that it will not be closed for inactivity, and what genuinely speeds up review (rebased branch, green CI, one claim per PR, signed-off commits). The message lives in .github/pr-acknowledgement.md rather than in the workflow, so the status can be edited -- or acknowledgements switched off by blanking the file -- without a workflow change. A missing, empty, or whitespace-only file is the documented off switch. Uses pull_request_target because a pull_request trigger hands fork PRs a read-only token, which would fail on exactly the contributions most worth acknowledging. The job never checks out, builds, or executes PR code: checkout carries no ref and so resolves to the base commit, it is used only to read our own message file, and the PR number reaches the shell through the environment rather than string interpolation. Skips bots and owner-authored PRs. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
DeusData
added
enhancement
DeusData
added
ux/behavior
…s ongoing The acknowledgement text described a state of the world that ended when 0.9.1-rc.1 published: it told every new contributor we were still finishing release-critical work and that "review resumes once the release path is clear". Posting that now would be false on the day it starts running. This is the obligation the PR description already set for itself -- the review-status section is a public promise and has to be edited when the situation it describes changes. Doing that before the workflow ever posts, rather than after someone reads a stale freeze notice, is the point. The queue is still real, so the section stays rather than being removed: the freeze is over, a large backlog is not, and PRs are being read oldest-first. Saying that is more useful to someone opening a PR today than either the old text or silence, because it explains why a recent PR sits behind older ones. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Contributors cannot tell blocked from ignored. Several PRs sat over a week on green, mergeable work with no maintainer comment while release-critical work absorbed capacity — and nothing on the PR page said so.
GitHub offers no repo-scoped information bar for pull requests. The org announcement banner renders only for organization members, and pinned issues and discussions never appear on the PR tab. Discussion #1144 explains the current situation well and is effectively invisible to someone opening a PR. A comment on open is the only surface that reaches an external contributor at the moment they contribute.
Change
Posts one comment when a PR is opened: it is queued, it will not be closed for inactivity, and here is what genuinely speeds up review (rebased branch, green CI, one claim per PR, signed-off commits).
The message text lives in
.github/pr-acknowledgement.md, not in the workflow. Edit that file to change what is said; blank it to switch acknowledgements off. No workflow change needed either way — a missing, empty, or whitespace-only file is the documented off switch (all three cases tested).Security note —
pull_request_targetThis is the repo’s first use of that trigger, so the reasoning is explicit.
It is required: a
pull_requesttrigger gives fork PRs a read-only token, so commenting would fail on exactly the contributions most worth acknowledging.What makes it safe is that the job never checks out, builds, or executes pull-request code:
actions/checkoutcarries noref:, so it resolves to the base commit (the default underpull_request_target), and is used only to read our own message file.persist-credentials: false.contents: readat top level,pull-requests: writeonly on the job.The workflow header states these constraints so a future edit does not quietly break them.
Behaviour
openedonly — one comment per PR, no repeat noise.user.type == Bot) and owner-authored PRs.Scope / risk
Non-gating; blocks no merge. One short job per opened PR. Worst case if the message file is malformed is a skipped comment, not a failed PR.
The standing obligation this creates: the review-status section is a public promise. It must be edited when the release path clears and removed when it stops being true — a stale freeze notice trains contributors to ignore status messages, which is worse than posting nothing.