DOC: Add API change section to reviewer docs

This seemed like the clearest place to add a more in-depth note
on it.  The actual table, etc. also would make sense, but there
you probably see the `MinVersion` anyway...

1 files changed, 28 insertions, 1 deletions

diff --git a/doc/source/dev/reviewer_guidelines.rst b/doc/source/dev/reviewer_guidelines.rst
index 8d938319e..c6b23ebef 100644
--- a/doc/source/dev/reviewer_guidelines.rst
+++ b/doc/source/dev/reviewer_guidelines.rst
@@ -101,7 +101,34 @@ For maintainers
   If a PR becomes inactive, maintainers may make larger changes. 
   Remember, a PR is a collaboration between a contributor and a reviewer/s, 
   sometimes a direct push is the best way to finish it.
- 
+
+API Changes
+-----------
+As mentioned most public API changes should be discussed ahead of time and
+often with a wider audience (mailinglist or even through a NEP).
+
+For changes in the public C-API be aware that the NumPy C-API is backwards
+compatible so that any addition must be ABI compatible with previous versions.
+When it is not the case, you must add a guard.
+
+For example ``PyUnicodeScalarObject`` struct contains the following::
+
+    #if NPY_FEATURE_VERSION >= NPY_1_20_API_VERSION
+        char *buffer_fmt;
+    #endif
+
+Because the ``buffer_fmt`` field was added to its end in NumPy 1.20 (all
+previous fields remained ABI compatible).
+Similarly, any function added to the API table in
+``numpy/core/code_generators/numpy_api.py`` must use the ``MinVersion``
+annotation.
+For example::
+
+    'PyDataMem_SetHandler':                 (304, MinVersion("1.22")),
+
+Header only functionality (such as a new macro) typically do not need to be
+guarded.
+
 GitHub Workflow
 ---------------