6 files changed, 32 insertions, 18 deletions
diff --git a/doc/neps/nep-0013-ufunc-overrides.rst b/doc/neps/nep-0013-ufunc-overrides.rst
index c132113db..d69af6924 100644
--- a/doc/neps/nep-0013-ufunc-overrides.rst
+++ b/doc/neps/nep-0013-ufunc-overrides.rst
@@ -20,6 +20,8 @@ NEP 13 — A mechanism for overriding Ufuncs
 :Date: 2017-03-31
 
 :Status: Final
+:Updated: 2023-02-19
+:Author: Roy Smart
 
 Executive summary
 =================
@@ -173,12 +175,12 @@ where in all current cases only a single output makes sense).
 
 The function dispatch proceeds as follows:
 
-- If one of the input or output arguments implements
+- If one of the input, output, or ``where`` arguments implements
   ``__array_ufunc__``, it is executed instead of the ufunc.
 
 - If more than one of the arguments implements ``__array_ufunc__``,
   they are tried in the following order: subclasses before superclasses,
-  inputs before outputs, otherwise left to right.
+  inputs before outputs, outputs before ``where``, otherwise left to right.
 
 - The first ``__array_ufunc__`` method returning something else than
   :obj:`NotImplemented` determines the return value of the Ufunc.
@@ -326,7 +328,10 @@ equivalent to::
     def __array_ufunc__(self, ufunc, method, *inputs, **kwargs):
         # Cannot handle items that have __array_ufunc__ (other than our own).
         outputs = kwargs.get('out', ())
-        for item in inputs + outputs:
+        objs = inputs + outputs
+        if "where" in kwargs:
+            objs = objs + (kwargs["where"], )
+        for item in objs:
             if (hasattr(item, '__array_ufunc__') and
                     type(item).__array_ufunc__ is not ndarray.__array_ufunc__):
                 return NotImplemented
diff --git a/doc/neps/nep-0019-rng-policy.rst b/doc/neps/nep-0019-rng-policy.rst
index c5c46603b..44033357a 100644
--- a/doc/neps/nep-0019-rng-policy.rst
+++ b/doc/neps/nep-0019-rng-policy.rst
@@ -17,7 +17,7 @@ Abstract
 For the past decade, NumPy has had a strict backwards compatibility policy for
 the number stream of all of its random number distributions.  Unlike other
 numerical components in ``numpy``, which are usually allowed to return
-different when results when they are modified if they remain correct, we have
+different results when modified if the results remain correct, we have
 obligated the random number distributions to always produce the exact same
 numbers in every version.  The objective of our stream-compatibility guarantee
 was to provide exact reproducibility for simulations across numpy versions in
diff --git a/doc/neps/nep-0021-advanced-indexing.rst b/doc/neps/nep-0021-advanced-indexing.rst
index 7751d309b..4c7a16375 100644
--- a/doc/neps/nep-0021-advanced-indexing.rst
+++ b/doc/neps/nep-0021-advanced-indexing.rst
@@ -143,7 +143,7 @@ exactly.
 
 Vectorized indexing in particular can be challenging to implement with array
 storage backends not based on NumPy. In contrast, indexing by 1D arrays along
-at least one dimension in the style of outer indexing is much more acheivable.
+at least one dimension in the style of outer indexing is much more achievable.
 This has led many libraries (including dask and h5py) to attempt to define a
 safe subset of NumPy-style indexing that is equivalent to outer indexing, e.g.,
 by only allowing indexing with an array along at most one dimension. However,
diff --git a/doc/neps/nep-0029-deprecation_policy.rst b/doc/neps/nep-0029-deprecation_policy.rst
index 4eb2aa50f..ccb566227 100644
--- a/doc/neps/nep-0029-deprecation_policy.rst
+++ b/doc/neps/nep-0029-deprecation_policy.rst
@@ -127,7 +127,10 @@ Apr 14, 2023 3.9+   1.21+
 Jun 23, 2023 3.9+   1.22+
 Jan 01, 2024 3.9+   1.23+
 Apr 05, 2024 3.10+  1.23+
-Apr 04, 2025 3.11+  1.23+
+Jun 22, 2024 3.10+  1.24+
+Dec 18, 2024 3.10+  1.25+
+Apr 04, 2025 3.11+  1.25+
+Apr 24, 2026 3.12+  1.25+
 ============ ====== =====
 
 
@@ -150,7 +153,10 @@ Drop Schedule
   On Jun 23, 2023 drop support for NumPy 1.21 (initially released on Jun 22, 2021)
   On Jan 01, 2024 drop support for NumPy 1.22 (initially released on Dec 31, 2021)
   On Apr 05, 2024 drop support for Python 3.9 (initially released on Oct 05, 2020)
+  On Jun 22, 2024 drop support for NumPy 1.23 (initially released on Jun 22, 2022)
+  On Dec 18, 2024 drop support for NumPy 1.24 (initially released on Dec 18, 2022)
   On Apr 04, 2025 drop support for Python 3.10 (initially released on Oct 04, 2021)
+  On Apr 24, 2026 drop support for Python 3.11 (initially released on Oct 24, 2022)
 
 
 Implementation
@@ -284,6 +290,9 @@ Code to generate support and drop schedule tables ::
   Jun 22, 2021: NumPy 1.21
   Oct 04, 2021: Python 3.10
   Dec 31, 2021: NumPy 1.22
+  Jun 22, 2022: NumPy 1.23
+  Oct 24, 2022: Python 3.11
+  Dec 18, 2022: NumPy 1.24
   """
 
   releases = []
diff --git a/doc/neps/nep-0046-sponsorship-guidelines.rst b/doc/neps/nep-0046-sponsorship-guidelines.rst
index ed54c21d5..746a73f5d 100644
--- a/doc/neps/nep-0046-sponsorship-guidelines.rst
+++ b/doc/neps/nep-0046-sponsorship-guidelines.rst
@@ -108,11 +108,12 @@ About page) will be added to acknowledge all current and previous sponsors,
 partners, and any other entities and individuals who provided $5,000 or more of
 financial or in-kind support. This page will include relevant details of
 support (dates, amounts, names, and purpose); no logos will be used on this
-page. The rationale for the $5,000 minimum level is to keep the amount of work
-maintaining the page reasonable; the level is the equivalent of, e.g., one GSoC
-or a person-week's worth of engineering time in a Western country, which seems
-like a reasonable lower limit.
-
+page. Such support, if provided for a specific enhancements or fix, may be
+acknowledged in the appropriate release note snippet. The rationale for the
+$5,000 minimum level is to keep the amount of work maintaining the page
+reasonable; the level is the equivalent of, e.g., one GSoC or a person-week's
+worth of engineering time in a Western country, which seems like a reasonable
+lower limit.
 
 Implementation
 --------------
@@ -128,7 +129,6 @@ The following content changes need to be made:
 - Update https://numpy.org/about with details on how to get in touch with the
   NumPy project about sponsorship related matters (see next section).
 
-
 NumPy Funding Team
 ~~~~~~~~~~~~~~~~~~
 
diff --git a/doc/neps/nep-0051-scalar-representation.rst b/doc/neps/nep-0051-scalar-representation.rst
index 851f173de..1e6f27a5f 100644
--- a/doc/neps/nep-0051-scalar-representation.rst
+++ b/doc/neps/nep-0051-scalar-representation.rst
@@ -70,7 +70,7 @@ Even ``np.float64``, which is very similar to Python's ``float`` and inherits
 from it, does behave differently for example when dividing by zero.
 
 Another common source of confusion are the NumPy booleans.  Python programmers
-somtimes write ``obj is True`` and will surprised when an object that shows
+sometimes write ``obj is True`` and will surprised when an object that shows
 as ``True`` fails to pass the test.
 It is much easier to understand this behavior when the value is
 shown as ``np.True_``.
@@ -96,7 +96,7 @@ Jupyter notebook cells will often show the type information intact.
 
     np.longdouble('3.0')
 
-to allow round-tripping.  Addtionally to this change, ``float128`` will
+to allow round-tripping.  Additionally to this change, ``float128`` will
 now always be printed as ``longdouble`` since the old name gives a false
 impression of precision.
 
@@ -137,7 +137,7 @@ The proposal is to change the default (back) to use ``str`` rather than
 Detailed description
 ====================
 
-This NEP proposes to change the represenatation for NumPy scalars to:
+This NEP proposes to change the representation for NumPy scalars to:
 
 * ``np.True_`` and ``np.False_`` for booleans (their singleton instances)
 * ``np.scalar(<value>)``, i.e. ``np.float64(3.0)`` for all numerical dtypes.
@@ -202,8 +202,8 @@ to always print as ``longdouble`` and never ``float128`` or ``float96``.
 It does not include deprecating the ``np.float128`` alias.
 However, such a deprecation may occur independently of the NEP.
 
-Integer scalar type name and instance represenatation
------------------------------------------------------
+Integer scalar type name and instance representation
+----------------------------------------------------
 
 One detail is that due to NumPy scalar types being based on the C types,
 NumPy sometimes distinguishes them, for example on most 64 bit systems
@@ -263,7 +263,7 @@ allowing customized formatting for all DTypes.
 
 Making ``get_formatter`` public allows it to be used for ``np.record`` and
 masked arrays.
-Currenlty, the formatters themselves seem semi-public; using a single
+Currently, the formatters themselves seem semi-public; using a single
 entry-point will hopefully provide a clear API for formatting NumPy values.
 
 The large part for the scalar representation changes had previously been done