docs(github): review the non-workflow metadata under .github/

.github/FUNDING.yml

@@ -1,12 +1,10 @@
-# These are supported funding model platforms
+# Platforms behind the repository's sponsor button.
+#
+# Only the platforms actually configured are listed. GitHub's commented-out
+# roster of every other platform used to sit below, but those lines were
+# instructions to whoever adopted the file rather than configuration, and one of
+# them (`otechie`) is no longer a platform GitHub documents.
 
-github: jarryshaw # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
-patreon: jarryshaw # Replace with a single Patreon username
-open_collective: # Replace with a single Open Collective username
-ko_fi: # Replace with a single Ko-fi username
-tidelift: pypi/pypcapkit # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
-community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
-liberapay: # Replace with a single Liberapay username
-issuehunt: # Replace with a single IssueHunt username
-otechie: # Replace with a single Otechie username
-custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
+github: jarryshaw
+patreon: jarryshaw
+tidelift: pypi/pypcapkit

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,24 +1,42 @@
 ---
 name: Bug report
 about: Create a report to help us improve
+labels: bug
 
 ---
 
 **Describe the bug**
 A clear and concise description of what the bug is.
 
+**Reproduction**
+The shortest script or command that shows the problem, followed by the output you
+actually got from running it. A reproduction that was executed is worth much more
+than one written from memory, so please paste real output rather than describing
+it. If a capture file is needed to trigger it, attach one -- and **strip anything
+sensitive from a capture first**, since a pcap taken from a real network usually
+carries more than the bug.
+
+**Expected behavior**
+A clear and concise description of what you expected to happen. Where a value is
+simply wrong, the most useful form is the observed value next to the expected one.
+
 **System information**
 A clear and concise description of your system information.
  - OS Version: [e.g. macOS 15.3, Ubuntu 24.04, Windows 11]
  - Python Version: [e.g. 3.14, 3.12, 3.10]
  - Python Implementation: [e.g. CPython, PyPy]
- - `pcapkit` Version: [e.g. 1.5.0b4; `python -c "import pcapkit; print(pcapkit.__version__)"`]
+ - `pcapkit` Version: [`python -c "import pcapkit; print(pcapkit.__version__)"`]
+ - If you are working from a checkout rather than an installed release, please give
+   the commit too [`git rev-parse --short HEAD`]. The version string alone does not
+   identify the tree, and an editable install can resolve to something well behind
+   the branch you think you are on.
 
 **Traceback stack**
-Run program again with `PCAPKIT_DEVMODE=true` set to provide the traceback stack.
-
-**Expected behavior**
-A clear and concise description of what you expected to happen.
+If the bug raises, run the program again with `PCAPKIT_DEVMODE=true` set and paste
+the traceback. Plenty of defects are silent rather than fatal -- if nothing is
+raised, say so and leave this section out.
 
 **Additional context**
-Add any other context about the problem here.
+Add any other context about the problem here. If you have already found the
+offending code, an exact `file:line` is the single most useful thing you can
+include; so is a note on why the existing tests do not catch it.

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,31 @@
+# The "New issue" chooser.
+#
+# ``blank_issues_enabled`` is deliberately true. Most issues here are filed by the
+# maintainer without a template, and turning it off would remove that route from
+# the web UI for no gain.
+#
+# The security link exists because ``SECURITY.md`` asks reporters not to open a
+# public issue for anything exploitable, and until now the chooser offered no way
+# to comply -- the only visible route was the public bug template.
+
+blank_issues_enabled: true
+
+contact_links:
+  - name: Report a security vulnerability
+    url: https://github.com/JarryShaw/PyPCAPKit/security/advisories/new
+    about: >-
+      Please do not open a public issue for a security problem. This opens a
+      private advisory visible only to the maintainer, so a patch can be prepared
+      before anything is public. See SECURITY.md for what to include.
+
+  - name: Ask a question, or get usage help
+    url: https://github.com/JarryShaw/PyPCAPKit/discussions
+    about: >-
+      For "how do I ...?" rather than "this is broken". Discussions keep the issue
+      tracker for defects and feature requests.
+
+  - name: Read the documentation
+    url: https://jarryshaw.github.io/PyPCAPKit/
+    about: >-
+      The API reference and per-protocol documentation, which answers most usage
+      questions faster than an issue will.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,6 +1,7 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
+labels: enhancement
 
 ---
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -4,15 +4,23 @@
 - Put an `x` into all the boxes [ ] relevant to your *pull request* (like that [x])
 - Use *Preview* tab to see how your *pull request* will actually look like
 
-- [ ] [Searched](https://github.com/JarryShaw/PyPCAPKit/search?q=is%3Apr&type=Issues) for similar pull requests
+- [ ] [Searched](https://github.com/JarryShaw/PyPCAPKit/pulls?q=is%3Apr) for similar pull requests
 - [ ] Followed the [coding style](https://github.com/JarryShaw/PyPCAPKit/blob/main/CONTRIBUTING.md#coding-style) (`make pylint`, `make mypy`, `make isort`)
 - [ ] `make test` passes, and a test case covers the change
 - [ ] Added a [changelog entry](https://github.com/JarryShaw/PyPCAPKit/blob/main/CONTRIBUTING.md#changelog-entries) under `docs/source/changelog/` and regenerated `CHANGELOG.md`, if the change is user-visible
 
 ### What is the purpose of your *pull request*?
-- [ ] Bug fix
-- [ ] Improvement
-- [ ] New feature
+
+Tick the [commit type](https://github.com/JarryShaw/PyPCAPKit/blob/main/CONTRIBUTING.md#format-of-the-commit-message) your subject line carries.
+
+- [ ] `fix` — corrects a defect
+- [ ] `feat` — adds a feature
+- [ ] `perf` — changes performance, not behaviour
+- [ ] `refactor` — changes neither behaviour nor performance
+- [ ] `test` — tests only
+- [ ] `docs` — documentation only
+- [ ] `ci` — workflows or build tooling
+- [ ] `chore` — anything else
 
 ---
 

.github/release.yml

@@ -1,13 +1,29 @@
 # .github/release.yml
+#
+# Categories for GitHub's automatically generated release notes. These are live:
+# `create-release.yml` asks for the generated notes with
+# `generate_release_notes: true` and the action joins them after the release body,
+# so on a normal release they follow the `CHANGELOG.md` entry, and on a
+# pre-release or a `.postN` vendor refresh -- neither of which has a changelog
+# entry of its own -- they are the whole of the notes.
+#
+# Categorisation keys on pull-request *labels*, and on nothing else. There is no
+# matching on the `type(scope):` subject prefix this project actually uses, so the
+# type a pull request announces in its title cannot reach this file. In practice
+# only Dependabot labels anything, which is why the catch-all is no longer titled
+# "Features": across the last 40 merged pull requests 24 were `fix`, 6 `test`,
+# 6 `docs`, 2 `feat` and 1 `perf`, so a Features heading described two of them and
+# mislabelled the rest.
+#
+# `*` catches the pull requests that "didn't match any of the previous
+# categories", so it has to come last. With the dependency category ahead of it,
+# no `exclude` is needed to keep the two apart.
 
 changelog:
   categories:
-    - title: 🏕 Features
-      labels:
-        - '*'
-      exclude:
-        labels:
-          - dependencies
     - title: 👒 Dependencies
       labels:
         - dependencies
+    - title: 🏕 Changes
+      labels:
+        - '*'