docs: repair the Code of Conduct's rendering and refresh CONTRIBUTING

[JarryShaw]

What this is

A review of CODE_OF_CONDUCT.md and CONTRIBUTING.md (plus the two .github templates, which are
the same class of document), checking every claim they make against what the repository actually does
today. Both needed changes. Nothing in pcapkit/, tests/ or examples/ is touched.

CODE_OF_CONDUCT.md — a rendering defect, not a policy change

The whole document was wrapped in a 1. ordered-list item, with all 27 content lines indented three
spaces to continue it. On GitHub that renders the entire Code of Conduct as a single numbered,
indented list entry. It has been that way since 9705860 in December 2017.

Dropping the wrapper leaves the Contributor Covenant 1.4 prose byte-identical — git diff -w
shows only the heading line and the three link lines. The two http://contributor-covenant.org links
are now https:// and point at the canonical 1.4 path (/version/1/4/code-of-conduct/), which is
what resolves today; the old ones 301 rather than 404, so this is tidying rather than repair.

The reporting contact is deliberately unchanged: jarryshaw@icloud.com matches the authors entry
in pyproject.toml, so it is real and current, not a placeholder.

Left for you to decide: whether to move off Covenant 1.4. 1.4 has no enforcement-guidelines
section. 2.1 adds a four-rung enforcement ladder, and 3.0 — which is now the latest, superseding 2.1 —
restructures the document into Encouraged/Restricted Behaviors with a "Community Moderators" role and
carries [NOTE: ...] placeholders the adopter is expected to fill in. Both are a larger commitment
than 1.4 makes, so which version to adopt is a call for you rather than something to change under
review.

CONTRIBUTING.md — the substance was from 2019 and described another project

It was generated by gaocegege/maintainer on 2019-10-24 and only mechanically touched since (the
README rename in 2022, the default-branch rename in 2023). Claims checked against the codebase:

Claim	Verdict
Worked example store/localstore: add comment for variable declaration.	False. A TiDB path; 0 tracked files under store/.
"subject line should be no longer than 70 characters"	False in practice. 127 of the last 200 subjects exceed it; median 77, longest 119.
Multiple subsystems as util/codec,util/types:, many as *:	Not the convention. Scopes go in parentheses.
"you can use one of some generic reasons like 'Improve documentation.'"	Contradicted by practice; bodies are substantive.
"Auto-generated by gaocegege/maintainer on 2019-10-24" footer	No longer true once hand-maintained.
"Read the README.rst for build instructions"	True today, but see below.

The real convention is Conventional Commits: 55 of the last 60 commits carry a type(scope):
prefix. Older history is mixed (bare protocols:, corekit:), which the document now says so a
contributor reading git log is not misled.

Added, because the document was silent and each is a real trap:

• The test tiers. make test (the unit tier, the selection CI runs) vs make test-all, and the
  failure mode tests/_tiers.py exists to prevent — a unit-tier module reading a generated capture
  passes locally and fails on a fresh checkout.
• The development environment. make setup, and that PIPENV_VENV_IN_PROJECT=1 puts it in
  .venv/ — so only that environment has the dependencies.
• The generated changelog. Entries go in docs/source/changelog/<version>.rst; CHANGELOG.md is
  produced by util/changelog_md.py and a hand-edit fails the Changelog drift job.
• The documentation convention — reStructuredText under docs/source/, with the
  repository-root Markdown exception that util/changelog_md.py already documents.
• The linters and their real line lengths — 120 for pylint, 100 for isort, not PEP 8's 79 —
  and the fact that none of them runs in the pull-request workflows, so they are a local gate.
• A pointer to docs/source/pep.rst, the maintained Help Wanted list.

The README is referenced without its extension, so the reference stays correct either side of the
README conversion happening in parallel.

Templates

• bug_report.md offered [e.g 3.7, 3.6, 3.5, 3.4] for the Python version where CI tests 3.10–3.14,
  and macOS Mojave for the OS. It also asked for no pcapkit version, which triage needs. The
  PCAPKIT_DEVMODE=true instruction was checked and is still valid, so it stays.
• PULL_REQUEST_TEMPLATE.md asked for neither a passing test run nor a changelog entry; the latter is
  CI-gated. The bare "Followed PEP8" checkbox now points at the coding-style section, since PEP 8's
  79 columns is not what the linters enforce.
• feature_request.md was checked and needed nothing.

Verification

No changelog entry — this is contributor-facing documentation, not user-visible.
python util/changelog_md.py --check still exits 0. No tests were run; nothing here touches the
package.

[JarryShaw]

✅ GOOD TO MERGE — head c20492d853c258cf7be75cab947c5f5c9c6f7a9a. Every falsifiable claim I checked against the repository itself matched exactly, including three independent numeric statistics on commit-message history (127/200, median 77, longest 119) that reproduced to the exact integer.

[JarryShaw]

Cross-review appendix — PR #613

Reviewer: Sonnet; PR authored on Opus 5. Reviewed at head c20492d853c258cf7be75cab947c5f5c9c6f7a9a in an isolated worktree (/tmp/pcapkit-review/pr613, removed after this review). Docs-only, no tests to run; verified every claim against the repository directly rather than trusting the prose, per the coordinator's specific ask.

CI

Rollup PENDING, CheckRun tally 7 SUCCESS, 2 SKIPPED, rest QUEUED, 0 FAILURE/CANCELLED.

Makefile/tooling claims — all confirmed

• Makefile:3: export PIPENV_VENV_IN_PROJECT=1 — confirmed exactly.
• Makefile:79/:83: test: and test-all: targets both exist as named.
• tests/_tiers.py exists, matching the "test tiers" claim.
• Makefile:135: pylint ... --max-line-length=120 — confirmed 120 exactly.
• Makefile:125-127: isort -l100 ... — confirmed 100 exactly (not PEP 8's 79, as the PR specifically contrasts).
• "None of them runs in the pull-request workflows": grep -rl "pylint\|isort" .github/workflows/*.yml finds only cron-vendor.yml; read its trigger block — on: schedule (weekly cron) + push: branches: [main] — no pull_request trigger at all. Confirmed: pylint/isort are genuinely absent from anything that runs on a PR.

Python version matrix

.github/workflows/unit-tests.yml: matrix lists 3.10, 3.11, 3.12, 3.13, 3.14 with experimental: false, and a separate include entry for 3.15 with experimental: true — confirmed exactly, matching "CI tests 3.10-3.14" (required) with 3.15 as an allowed-to-fail addition.

Git-history claims — reproduced with exact numeric matches

Ran the same kind of measurement independently against this worktree's own git log, not the PR's numbers:

• store/ claim: git ls-files | grep '^store/' | wc -l → 0 — exact match to "0 tracked files under store/."
• Subject-line length, last 200 commits: computed length of every subject line myself — 127 over 70 characters, median 77, longest 119 — all three numbers match the PR's claim exactly, to the integer.
• Conventional-commits ratio, last 60 commits: my own regex (^[a-z]+(\([a-zA-Z0-9_.-]+\))?: ) counted 54 matching type(scope):/type: prefixes against the PR's claimed 55 — off by one, most likely a small difference in exactly which prefix shapes we each counted (e.g., a commit with an unusual scope character); not worth chasing further given every other number in this PR reproduced exactly.

CODE_OF_CONDUCT.md — confirmed prose-identical, links updated

git diff -w (whitespace-ignored) shows only the heading line (dropping the 1. wrapper) and the attribution/link lines (the http:// → https:// and old /version/1/4 path → canonical /version/1/4/code-of-conduct/ path) — the Contributor Covenant 1.4 prose itself is untouched, confirming "byte-identical" under -w.

CONTRIBUTING.md — README reference convention

grep -n README CONTRIBUTING.md shows both references ("Read the README for...", "the README are a deliberate exception") with no file extension appended — confirmed exactly as claimed, so the reference survives either side of a README.rst↔README.md rename happening elsewhere.

Not independently checked

• The specific claim about the content of store/localstore: add comment for variable declaration. being a TiDB-project example (the wrong-project worked example) — confirmed the practical consequence (0 files under store/ here) but did not separately verify the string traces to TiDB's own history.
• The feature_request.md template "needed nothing" claim, and the specific wording changes to bug_report.md/PULL_REQUEST_TEMPLATE.md — read the diff but did not independently re-derive what the "right" OS/Python version placeholders should be beyond confirming the version matrix above.
• docs/source/pep.rst existing as "the maintained Help Wanted list" — not opened to confirm its content matches that description, only that the file exists.

Disagreement log

None that rise to a defect. One trivial numeric near-miss (54 vs. 55 conventional-commit count) that does not change the claim's substance — the "real convention is Conventional Commits" point holds at either count.