docs(contributing): correct four statements the recent merges falsified

[JarryShaw]

What is the purpose of this pull request?

• docs — documentation only

CONTRIBUTING.md had accumulated four statements that the tree no longer supports. One was the
reported defect; three came out of checking the rest of the file against da381f259 while in there.

1. The reported defect — "not run by the pull-request workflows"

CONTRIBUTING.md:104 read:

None of these is run by the pull-request workflows, so they are a local gate rather than something a
pull request will fail on. Running them anyway saves a review round.

#626 made that false when it added .github/workflows/lint.yml. The correction states, from the
workflow rather than from memory:

linter	in lint.yml?	triggers	blocking?
bandit	yes	pull_request → main, schedule Sat 06:00 UTC, workflow_dispatch	no — continue-on-error: true
mypy	yes	same	no — continue-on-error: true
vermin	yes (vermin-ci)	same	no — continue-on-error: true
pylint	yes	same	no — continue-on-error: true
isort	no	only cron-vendor.yml, as a formatter	n/a

Three things the new prose is careful about, because getting any of them wrong would mislead a
contributor in a new direction:

• Advisory, not blocking. All four steps carry continue-on-error: true
  (lint.yml:117,134,163,183), so a red linter cannot fail a pull request. "Linting runs in CI"
  without that qualifier would be worse than the stale sentence it replaces.
• isort is excluded. It is not in lint.yml at all; its only workflow appearance is inside
  cron-vendor.yml, re-sorting regenerated constants as a formatter rather than checking anything.
  Import ordering is still unverified on a pull request.
• make vermin does not fail on violations. Makefile:147-150 redirects into temp/vermin.txt
  and hands the file to code, falling back to cat, so the status returned is the viewer's.
  make vermin-ci (Makefile:158-159) is the target CI actually runs.

The text also records that CI invokes the same Makefile targets with RUN=, which is what keeps
local and CI from drifting, and points at the workflow header for the current counts rather than
copying numbers that will go stale.

2. Three further corrections

• CONTRIBUTING.md:11 claimed the README has a Testing section holding the test commands. It
  does not — the README's headings are Installation, Usage and Documentation, and its only
  mention of testing is a row in the Documentation table (README.md:97) linking to
  docs/source/testing.rst, which is where those commands moved.
• CONTRIBUTING.md:76 said the Changelog drift job runs "on every push and pull request". The
  job carries no if: guard, but its workflow's triggers are push: branches: [main] and
  pull_request: branches: [main], so it is scoped to main.
• CONTRIBUTING.md:86 said the Markdown exception "stops at the root". The three issue and
  pull-request templates under .github/ are Markdown for exactly the GitHub-rendering reason the
  root files are; the claim that actually holds is about docs/source/, which has no .md files.

3. Templates — assessed, and deliberately unchanged

The second half of the ask was whether the issue/PR templates need additions, including whether new
templates are warranted. Verdict: no change, on measured evidence rather than taste.

• blank_issues_enabled: true (.github/ISSUE_TEMPLATE/config.yml:11) — checked because a
  false here would actively obstruct the dense maintainer filing style. It is true, the file
  documents that as deliberate, and the YAML parses.
• Templates are already bypassed by the people whose shapes would motivate a new one. All 15
  issues filed in the last hour (the release pipeline publishes to PyPI and Anaconda with no approval gate: environment: release is commented out, and a vendor cron that bumps the version is enough to trigger it #641–Neither the HIP PUZZLE nor SOLUTION builder consults version when sizing, so HIPv1 rejects what it builds #655) carry zero labels, and bug_report.md auto-applies
  bug — so all 15 were blank issues. Across the whole tracker only 22 issues have ever carried
  bug and 3 enhancement, i.e. roughly 25 of 187 issues used a template at all. 149 of 187 issues
  are maintainer-filed.
• The RFC-conformance shape is the strongest candidate and still does not justify a template.
  HIP parameter padding aligns the contents, not the record, so every parameter pcapkit emits is 4 (mod 8) octets #651, Re-serialising a parsed HIP PUZZLE or SOLUTION loses leading zero octets: a len=20 parameter rebuilds as len=6 #653, SOLUTION's Reserved octet is written as a PUZZLE Lifetime, and lifetime=0 escapes a bare ValueError from math.log2 #654 and Neither the HIP PUZZLE nor SOLUTION builder consults version when sizing, so HIPv1 rejects what it builds #655 share a real structure — RFC section quoted verbatim (with the fetched
  document's sha256), bytes produced versus bytes required, and whether pcapkit round-trips its own
  error. But that structure is already richer than any scaffold of blank prompts, and its author
  files blank issues by design. A third entry in the "New issue" chooser would tax the one audience
  templates serve — the external newcomer — to serve a filer who never opens the chooser.
• External contribution volume caps the upside. Exactly 4 pull requests from external humans
  exist in the project's history (Ts-Boom ×2, lux-liang, yechielw); everything else is the
  maintainer or a bot. Issue filers outside the maintainer are 38 accounts filing once each.
• The three contact routes resolve. has_discussions: true and private vulnerability reporting
  enabled: true, so the links docs(github): review the non-workflow metadata under .github/ #637 added are live rather than dead ends.

This deliberately does not re-litigate #637, which added bug_report.md's Reproduction section,
expanded the PR template to the eight commit types at CONTRIBUTING.md:133, and added config.yml.
Its reasoning — that the template audience is the external newcomer, so the templates should not be
rewritten to imitate maintainer prose — is the reasoning this assessment follows.

Recommended but not done, as judgement calls for the owner rather than edits to make unilaterally:

1. A PR-template checkbox for "changes wire output or public API". fix(tcp): seed TCP.read's flag accumulator with Enum_Flags(0), not a no-op cast (#616) #634, fix(pcap): Frame.len is the on-wire length, cap_len the captured one (#618) #635 and fix(protocol): refuse a construction keyword no signature declares (#617) #640 all needed
   that flagged by hand. It is cheap — one line in an existing checklist, no chooser cost — but all
   three are maintainer-authored, and the maintainer uses the PR template in 0 of the last 20 PRs,
   so the box would be seen mainly by the 4-external-PR audience that does not make such changes.
2. PULL_REQUEST_TEMPLATE.md:8 names make pylint, make mypy, make isort and omits bandit
   and vermin. Not false — it reads as examples — but it is now a subset of what CI reports.

Notes

• No changelog entry, deliberately. None of this is user-visible, and a bullet here would collide
  with the changelog consolidation in flight across several PRs.
• .github/workflows/** was read-only throughout; no workflow was touched ahead of the 1.5.0b5
  release. No file outside CONTRIBUTING.md is modified.
• The test suite was not run — nothing here executes code. config.yml was validated by parsing it.
• One commit, authored Jarry Shaw <jarryshaw@icloud.com>, on top of da381f259.

[JarryShaw]

Cross-review verdict (Sonnet, independent of the model that wrote this PR)

NEEDS CHANGES

Posting this after the merge because the review was still running when this landed. All of it is
addressed in #659. Recording it here so the reasoning sits next to the change it was about.

The review was briefed to falsify rather than bless, and to give a verdict per claim with evidence it
obtained itself. It confirmed the load-bearing claims and raised three inaccuracies:

1. CONTRIBUTING.md:108 contradicted CONTRIBUTING.md:124 four lines apart. "The job invokes the
   same Makefile targets listed above" is false for vermin — lint.yml:166 runs make vermin-ci,
   which is not in the block above — and the later paragraph said so. Fixed in docs(contributing): the make vermin trap is the opposite of what was recorded #659.
2. "every step writes its count there" is wrong for vermin. lint.yml:173 emits version verdicts
   (Minimum required versions: / Target versions not met:), not counts; the reviewer checked this
   against vermin's own source strings in vermin/main.py:138,156,164. Fixed in docs(contributing): the make vermin trap is the opposite of what was recorded #659.
3. Changelog drift has a trigger this PR did not mention. The job carries no gate-only guard,
   so it also runs on every workflow_call into unit-tests.yml. Fixed in docs(contributing): the make vermin trap is the opposite of what was recorded #659, naming all four
   callers.

Confirmed by the review, with its own evidence: all four continue-on-error: true lines
(lint.yml:117,134,163,183), so the advisory claim holds; the trigger set and 0 6 * * 6 decoded to
Saturday 06:00 UTC with push genuinely absent; Python 3.14 single-version; isort absent from
lint.yml and only ever a bare rewrite in cron-vendor.yml, never a check; the README having no
Testing heading; the .github/ Markdown inventory, with a repo-wide sweep finding no other .md
anywhere; and the eight commit types, the quoted example commit, and the 120/100 line lengths.

It also noted a scope point worth keeping: checkout, setup-python and the install step carry no
continue-on-error, so the job can still fail on infrastructure. The prose says "a red linter will
not fail your pull request", which is scoped to findings, so it does not overclaim — but the job going
red is not always a linter talking.

Where the cross-review was itself wrong

It marked the make vermin exit-status claim CONFIRMED — agreeing with this PR that a run finding
violations "still looks like a success", on the grounds that A && B || C always returns the viewer's
status. That is the same error the Makefile and lint.yml comments make: it reasons about that line
in isolation and misses that the redirect is a separate recipe line, so make abandons the target
before reaching it. Measured rather than reasoned: make vermin RUN= exits 2 with
*** [vermin] Error 1, vermin exits 1 on Target versions not met: 3.6, and the viewer line never
runs — with a passing control that does reach it. #659 has the full evidence.

Two reviewers agreeing is not the same as the claim being true, which is the useful lesson here.