DOC: Copy edits from @willingc

This is the first batch of suggestions.

Co-Authored-By: Carol Willing <carolcode@willingconsulting.com>

1 files changed, 26 insertions, 26 deletions

diff --git a/doc/neps/nep-0029-deprecation_policy.rst b/doc/neps/nep-0029-deprecation_policy.rst
index a073dcf36..94d309ec0 100644
--- a/doc/neps/nep-0029-deprecation_policy.rst
+++ b/doc/neps/nep-0029-deprecation_policy.rst
@@ -12,20 +12,20 @@ NEP 29 — A standard community policy for dropping support of old Python and Nu
 Abstract
 --------
 
-All projects across the ecosystem should adopt a common time window
+This NEP recommends and encourages all projects across the Scientific Python ecosystem to adopt a common "time window-based" policy for support of Python and NumPy versions. Standardizing a recommendation for project support of minimum Python and NumPy versions will improve downstream project planning.
 based policy for increasing the minimum version of Python and NumPy
 that downstream projects support.  By standardizing this policy
 across the community we will make it easier for downstream projects to
 plan.
 
-This is an unusual NEP in that it is recommendations for community-wide
+This is an unusual NEP in that it offers recommendations for community-wide
 policy and not for changes to NumPy itself.  However, we do not
 currently have a place for SPEEPs (Scientific Python Ecosystem
 Enhancement Proposals) and given NumPy's central role in our community
 this seems like the proper place to document this.
 
 
-This is being put forward by maintainers of Matplotlib, scikit-learn,
+This NEP is being put forward by maintainers of Matplotlib, scikit-learn,
 IPython, Jupyter, yt, SciPy, NumPy, and scikit-image.
 
 
@@ -33,9 +33,9 @@ IPython, Jupyter, yt, SciPy, NumPy, and scikit-image.
 Detailed description
 --------------------
 
-When making a new major or minor release, projects should support all
-minor versions of ``Python`` initially released in the prior 42
-months from their anticipated release date and all minor version of
+When a project creates a new major or minor release, we recommend that the project should support all
+minor versions of ``Python`` introduced and released in the prior 42
+months ~~from their anticipated release date~~ and all minor versions of
 NumPy released in the prior 24 months.
 
 
@@ -50,7 +50,7 @@ The diagram::
             |-----------------------------------------> Dec19
                       |-----------------------------------------> Nov20
 
-shows the support windows for ``Python``.  A project with a major or
+shows the 42 month support windows for ``Python``.  A project with a major or
 minor release in Feb19 should support py35 and newer, a project with a
 major or minor release in Dec19 should support py36 and newer, and a
 project with a major or minor release in Nov20 should support py37 and
@@ -61,18 +61,18 @@ ensures that there will always be at least two versions of ``Python``
 in the window.  By padding the window by 6 months from the anticipated
 ``Python`` cadence we avoid the edge cases where a project releases
 the month after ``Python`` and would effectively only support one
-version of ``Python`` that has an install base (and then the window
-is 42).  This buffer also makes us resilient to minor fluctuations /
+version of ``Python`` that has an installed base.
+This six month buffer provides resilience to minor fluctuations /
 delays in the ``Python`` release schedule.
 
-Because the threshold for dropping a version of ``Python`` is based
-on historical release dates and a project's plans, the decision to drop
-support for a given version of ``Python`` can be made very early in
+Because ``Python`` version support is based
+on historical release dates, a 42 month time window, and a project's plans, a project can decide to drop
+a given version of ``Python`` very early in
 the release process.
 
-There will be some unavoidable mismatch in supported version of
-``Python`` between packages immediately after a version of
-``Python`` ages out.  However this should not last longer than one
+While there will be some unavoidable mismatch in supported version of
+``Python`` between if a project release occurs immediately after a version of
+``Python`` ages out.  This should not last longer than one
 release cycle of each of the projects, and when a given project
 does a minor or major release, it is guaranteed that there will be a
 stable release of all other projects that support the set of
@@ -90,19 +90,19 @@ We suggest that all projects adopt the following language into their
 development guidelines:
 
 
-   - support minor versions of ``Python`` initially released
-     42 months prior to our planned release date
-   - always support at least the 2 latest minor versions of ``Python``
+   - This project supports minor versions of ``Python`` initially released
+     42 months prior to a planned project release date.
+   - The project will always support at least the 2 latest minor versions of ``Python``
    - support minor versions of ``numpy`` initially released in the 24
-     months prior to our planned release date or oldest that supports the
+     months prior to a planned project release date or the oldest version that supports the
      minimum Python version (whichever is higher)
 
    The minimum supported version of ``Python`` will be set to
-   ``python_requires`` in ``setup`` and all supported versions of
+   ``python_requires`` in ``setup``.  All supported versions of
    Python will be in the test matrix and have binary artifacts built
    for releases.
 
-   We will bump the minimum Python and NumPy versions as we can on
+   The project will bump (adjust upward) the minimum Python and NumPy version support on
    every minor and major release, but never on a patch release.
 
 For other dependencies, adopt similar time windows of 24 months or
@@ -122,15 +122,15 @@ Alternatives
 Ad-Hoc
 ~~~~~~
 
-Projects could on every release evaluate if they want to increase
-the minimum version of Python supported.  While this is a notionally
-simple policy, it makes it hard for downstream users to predict what
+A project could on every release evaluate whether to increase
+the minimum version of Python supported.
+As a major downside, an ad-hoc approach makes it hard for downstream users to predict what
 the future minimum versions will be.  As there is no objective threshold
 to when the minimum version should be dropped, it is easy for these
-discussions to devolve into [bike shedding](https://en.wikipedia.org/wiki/Wikipedia:Avoid_Parkinson%27s_bicycle-shed_effect) and acrimony.
+version support discussions to devolve into [bike shedding](https://en.wikipedia.org/wiki/Wikipedia:Avoid_Parkinson%27s_bicycle-shed_effect) and acrimony.
 
 
-All Python Software Foundation supported versions
+All CPython supported versions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This is a very clear and conservative approach.  However, it means that