diff --git a/pkgs/README.md b/pkgs/README.md
index 6201839f23c45..e7388c40b3e9c 100644
--- a/pkgs/README.md
+++ b/pkgs/README.md
@@ -946,6 +946,11 @@ Reviewing process:
 - Verify any change of upstream.
   - If switching from e.g. PyPi to GitHub, verify that the repo is the official one.
   - If switching to a fork, check with external sources like other package repositories for community consensus.
+- Ensure any special packaging choices and required context are documented in i.e. the name of a patch or in a comment.
+  - If a special version of a package is pinned, document why, so others know if/when it can be unpinned.
+  - If any (especially opinionated) patch or `substituteInPlace` is applied, document why.
+  - If any non-default build flags are set, document why.
+  - If checks are partially or fully disabled, document why.
 - Ensure that the code contains no typos.
 - Build the package locally.
   - Pull requests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds.
@@ -977,6 +982,7 @@ Sample template for a package update review is provided below.
 - [ ] package builds on ARCHITECTURE
 - [ ] executables tested on ARCHITECTURE
 - [ ] any change of upstream are verified
+- [ ] the motives for any special packaging choices are documented
 - [ ] all depending packages build
 - [ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed
 - [ ] patches that are remotely available are fetched rather than vendored
@@ -1002,6 +1008,11 @@ Review process:
   - Platforms should be set (or the package will not get binary substitutes).
   - Maintainers must be set. This can be the package submitter or a community member that accepts taking up maintainership of the package.
   - The `meta.mainProgram` must be set if a main executable exists.
+- Ensure any special packaging choices and required context are documented in i.e. the name of a patch or in a comment.
+  - If a special version of a package is pinned, document why, so others know if/when it can be unpinned.
+  - If any (especially opinionated) patch or `substituteInPlace` is applied, document why.
+  - If any non-default build flags are set, document why.
+  - If checks are partially or fully disabled, document why.
 - Report detected typos.
 - Ensure the package source:
   - Uses `mirror://` URLs when available.
@@ -1027,6 +1038,7 @@ Sample template for a new package review is provided below.
 - [ ] build time only dependencies are declared in `nativeBuildInputs`
 - [ ] source is fetched from an official or trusted location
 - [ ] source is fetched using the appropriate function
+- [ ] the motives for any special packaging choices are documented
 - [ ] the list of `phases` is not overridden
 - [ ] when a phase (like `installPhase`) is overridden it starts with `runHook preInstall` and ends with `runHook postInstall`.
 - [ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed