docs: credit timwukp in the README contributors block - #8341
docs: credit timwukp in the README contributors block#8341chenmingwei23 wants to merge 1 commit into
Conversation
Records the credit requested in #8137 through CONTRIBUTING's documented "credited on request" path, for the investigation and design behind the remote-crew DNS-shadowing preflight. The automatic reporter rule already derives this person as the reporter of #7522 (closed by merged #7888), so this line is not a substitute for that rule -- it is the same one line, delivered now rather than waiting on the contributors PR handoff in #6741. The script dedups against every GitHub profile link in the README, so the later automated run treats this entry as already present and never duplicates it. Refs #8137
github-actions
Bot
added
the
readiness: checking
Opus 4.8 Review — ✅ no blocking findingsReviewed Verdict parsed from the review's SHA-scoped output markers for commit False positive or not applicable? A repository writer can comment: |
Design Review (Fable 5) — ✅ PASSDesign-level review of Design-Verdict: PASS One-line credit via the documented script, correctly sorted, idempotent against the pending automated sweep — no design-level concerns. [DESIGN-REVIEWED] c1ece3c |
GPT 5.6 Review — ✅ no blocking findingsGPT 5.6 completed its review of This comment is updated in place on each push. Review detailsNo findings. False positive or not applicable? A repository writer can comment: |
github-actions
Bot
added
readiness: action required
1 participant
Measured at 2026-09-04T00:45:52Z against main
711544f3d87a838657349849ad0e9c3883e882d4.Problem / Motivation
#8137 is a credit request
filed through the path
CONTRIBUTING.mddocuments: "Open an issue naming theperson (yourself is fine), and a maintainer records it," with the exact command
to run. The request is for the investigation and design behind the remote-crew
DNS-shadowing preflight now on
main(reported as#7522, implemented via
#7553, merged as
#7888).
The issue also reports that the automatic reporter-credit rule did not fire
for #7522. That second claim does not survive the code: the rule fired. The
detail is under "What changed"; it is not fixed here, and it is not fixable in
this repository's code.
Why it matters
A person asked to be credited by a path the project publishes and told them to
use. The document fixes both the path and the value, so recording it is a lookup,
not a judgement.
What changed (motivation -> approach -> change)
One line in the README Contributors block, produced by running the documented
command rather than hand-editing:
python3 scripts/update_contributors.py --login timwukp --name "Tim WU"Why this is not a workaround for a broken rule. The reporter half of the
automatic rule is working. Run
33725275383(2026-09-03T06:52:23Z, the run theissue cites) logs:
closingIssuesReferenceson merged #7888 resolves #7522 totimwukp/User,which is exactly the input
add-contributor.ymlcredits, and the login isalready present in the README on the pushed rolling branch
chore/add-contributors(3aaa1140a6d91195d79c5ae4ca930031673810fb, pushed2026-09-03T06:53:42Z).
What did not happen is delivery. The same run then logs:
The workflow takes its documented handoff path there, keeps the run green on
purpose, and comments the compare link on
#6741, which it has now
done on six consecutive daily runs (2026-08-30 through 2026-09-03) with no human
action since 2026-08-29. So the visible symptom the issue reports is real, the
run really was green, and the README really lacks the entry; the inference that
the issue-reporter half is silently not running is the part that does not hold.
It is one un-opened pull request withholding every contributor discovered
since 2026-08-29, PR authors and issue reporters alike, not reporters
specifically.
That blocker is deliberately not addressed here. Resolving it needs either a
human to open the contributors PR, or a repo admin to enable "Allow GitHub
Actions to create and approve pull requests", one switch that also grants
workflows PR approval and so weakens
main's required-human-approval gate.The workflow's own comment forbids the third option (
Do not "fix" that by making the step fail again -- it did, daily, unnoticed for weeks). #6741 isalready routed
needs-humanwith that exact ruling recorded.Tests
No new test: the input the issue believed was non-firing demonstrably fires, so
there is no non-firing input to pin. The behaviour this change depends on, that
a manually-added entry is never re-added or duplicated by the later automated
sweep, is already covered and was re-run against this diff.
Manual verification
Against this branch, on top of
711544f3d:No new contributors; README already up to date.[{"login":"timwukp",...},{"login":"TIMWUKP",...}]:No new contributors; README already up to date.grep -c 'github.com/timwukp"' README.mdreturns1git status --shortshowsM README.mdonly.So when the rolling PR in #6741 does land, it will not produce a second entry.
Screenshots / video
None: one text line in a list, no rendered surface change beyond an added avatar.
Related Issues
Refs #8137
Refs #6741
Pattern harvest
A green scheduled run and a correct observation of its absent output can
coexist without the derivation being at fault. This workflow ends in a
best-effort
gh pr createthat is expected to be refused, so its successconclusion says nothing about whether its result reached
main. When acredit/report/sync job "did not fire", read the pushed branch and the job log
before the deriving code: the branch carries the answer, and here it already
held the entry.
Checklist
Contribution License Agreement
By submitting this pull request I confirm that my contribution is made under the
terms of the project's license.