chore(docs): centralise changelog entries for unreleased versions

.github/PULL_REQUEST_TEMPLATE.md

@@ -7,7 +7,7 @@
 - [ ] [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
+- [ ] Described the user-visible change below and left its [changelog entry](https://github.com/JarryShaw/PyPCAPKit/blob/main/CONTRIBUTING.md#changelog-entries) to the maintainer, keeping `docs/source/changelog/` and `CHANGELOG.md` out of the diff, if the change is user-visible
 
 ### What is the purpose of your *pull request*?
 

CONTRIBUTING.md

@@ -25,7 +25,8 @@ A rough outline:
 - Create a topic branch, usually from `main`.
 - Make commits of logical units, and add a test case if the change fixes a bug or adds functionality.
 - Run the tests and make sure they pass (see below).
-- Add a changelog entry if the change is user-visible (see below).
+- If the change is user-visible, describe it in the pull request and leave its changelog entry to
+  the maintainer (see below).
 - Make sure your commit messages are in the proper format (see below).
 - Push your changes to a topic branch in your fork of the repository.
 - Submit a pull request to the repo.
@@ -58,10 +59,15 @@ shapes of it at collection time and say what to do; `tests/_tiers.py` has the re
 Entries live in `docs/source/changelog/<version>.rst`, one file per version, listed newest-first in
 the toctree of `docs/source/changelog.rst`. That tree is the single source of the project's history.
 
+**Pull requests for user-visible changes do not add their own bullet.** While a version is
+unreleased, its entry is written centrally by the maintainer once a change is ready to merge or has
+merged. Pull requests that each edit the same file conflict on every merge, so leave
+`docs/source/changelog/<version>.rst` and `CHANGELOG.md` out of the diff.
+
 **`CHANGELOG.md` is generated — never edit it by hand.** `util/changelog_md.py` derives it from the
 newest entry alone, because its consumers (the `Create Release` workflow's release body and the
-source distribution) read Markdown rather than reStructuredText. Add your bullet to the `.rst`
-entry, then regenerate:
+source distribution) read Markdown rather than reStructuredText. The maintainer adds the bullet to
+the `.rst` entry, then regenerates:
 
 ```shell
 python util/changelog_md.py            # rewrite CHANGELOG.md from the newest entry

docs/source/changelog/1.5.0.rst

@@ -1143,8 +1143,8 @@ Fixed
   ``register_reassembly`` and ``register_traceflow`` on :class:`.Extractor`,
   :meth:`.TraceFlow.register_dumper` (reached
   through ``register_traceflow_dumper``), and
-  :func:`pcapkit.foundation.registry.protocols.register_protocol`. Each guard gains an
-  explicit ``isinstance(x, type)`` test ahead of its ``issubclass``; in those that
+  :func:`pcapkit.foundation.registry.protocols.register_protocol <pcapkit.foundation.registry.protocols.protocol.register_protocol>`.
+  Each guard gains an explicit ``isinstance(x, type)`` test ahead of its ``issubclass``; in those that
   accept a :class:`.ModuleDescriptor` it runs after the descriptor is unwrapped, so a
   descriptor naming a non-class attribute is rejected too, while ``register_protocol``
   takes no descriptor. No guard's target class changes, and a wrong class still raises
@@ -1239,8 +1239,8 @@ Fixed
   and ``register_transtype`` refuse a ``code`` that is not an enum member with
   :exc:`.RegistryError` before touching a registry, where they registered it and then
   raised ``AttributeError``, leaving the entry behind (:issue:`2186`, :pr:`2193`).
-* :func:`pcapkit.foundation.registry.protocols.register_protocol_code`, and the
-  ``code=`` class keyword, check every destination's key before registering any of
+* :func:`pcapkit.foundation.registry.protocols.register_protocol_code <pcapkit.foundation.registry.protocols.protocol.register_protocol_code>`,
+  and the ``code=`` class keyword, check every destination's key before registering any of
   them. A key belonging to another enum, such as ``{Frame: TransType.ICMP}``, is
   refused with :exc:`.RegistryError` where it replaced the shipped
   ``LinkType.ETHERNET`` entry, and a bad target late in the list no longer leaves
@@ -1382,8 +1382,8 @@ Added
   Inference refuses rather than guesses: an enum member whose type names no known
   destination raises :exc:`.RegistryError`, and an unrecognised class keyword raises
   :exc:`.UnsupportedCall`, matching the other registrar families. Backed by
-  :func:`pcapkit.foundation.registry.protocols.register_protocol_code`, also callable
-  directly for a class that declined at definition time. It was written up as the
+  :func:`pcapkit.foundation.registry.protocols.register_protocol_code <pcapkit.foundation.registry.protocols.protocol.register_protocol_code>`,
+  also callable directly for a class that declined at definition time. It was written up as the
   mechanism :issue:`548` needs; :issue:`548` turned out to need a missing class instead
   (115 is :rfc:`3931` L2TPv3 over IP, not :rfc:`2661`; see the corresponding **Fixed**
   entry below), so its worked example names ``L2TPv3`` (:pr:`570`).