address review

Author: Aloqeely

web/pandas/pdeps/0017-backwards-compatibility-and-deprecation-policy.md

@@ -20,15 +20,11 @@ This policy will ensure that users have enough time to deal with deprecations wh
 
 This PDEP covers pandas' approach to backwards compatibility and the deprecation and removal process.
 
-The decision making process for deprecating features is out of scope for this PDEP.
-
 ## Background
 
 pandas uses a loose variant of semantic versioning.  
 A pandas release number is written in the format of ``MAJOR.MINOR.PATCH``.
 
-For the purposes of this PDEP, the last minor release before a major release will be referred to as the 'final minor version'.
-
 ## General policy
 
 This policy applies to the [public API][1]. Anything not part of the [public API][1] or is marked as "Experimental" may be changed or removed at anytime.
@@ -37,6 +33,7 @@ This policy applies to the [public API][1]. Anything not part of the [public API
 - Breaking changes should go through a deprecation cycle before being implemented.
 - Breaking changes should only occur in major releases.
 - No deprecations should be introduced in patch releases.
+- Deprecated functionality should remain unchanged for at least 6 months before being changed or removed.
 
 Some bug fixes may require breaking backwards compatibility. In these cases, a deprecation cycle is not necessary. However, bug fixes which have a large impact on users might be treated as a breaking change. Whether or not a change is a bug fix or an API breaking change is a judgement call.
 
@@ -58,26 +55,18 @@ Additionally, when one introduces a deprecation, they should:
 
 ### Which warning class to use
 
-Deprecations should initially use ``DeprecationWarning``, and then be switched to ``FutureWarning`` for broader visibility in the final minor version before the major release they are planned to be removed in.  
+Deprecations should initially use ``DeprecationWarning``, and then be switched to ``FutureWarning`` for broader visibility in the last minor release before the major release they are planned to be removed in.  
 This implementation detail can be ignored by using the appropriate ``PandasDeprecationWarning`` variable, which will be aliased to the proper warning class based on the pandas version.
 
-Not all deprecations have to use ``DeprecationWarning`` but all deprecations should eventually transition to ``FutureWarning``, i.e. deprecations in the final minor version which are planned to be removed in the major release after will immediately use ``FutureWarning``.
-
-It is recommended to not introduce large-scale deprecations in the final minor version which are planned to be removed in the major release after, since that will immediately be using a loud ``FutureWarning`` with not much time between deprecation and removal. Instead, a ``DeprecationWarning`` should be used, and the removal should be scheduled for a later major release.
-
-### Support window for the final minor version
-
-Defining a release policy is not part of this PDEP's scope, but, the final minor version plays a special role in deprecations, since:
-- It is the version where deprecations planned for removal in the next major release get switched from a ``DeprecationWarning`` to a more visible ``FutureWarning``.
-- ``FutureWarning`` deprecations released in it will immediately be removed in the next major release.
+Not all deprecations have to use ``DeprecationWarning`` but all deprecations should eventually transition to ``FutureWarning``, i.e. deprecations in the last minor release which are planned to be removed in the major release after will immediately use ``FutureWarning``.
 
-And so, this document recommends a minimum of 6 months between the final minor version and the major release after it.
+It is recommended to not introduce large-scale deprecations in the last minor release which are planned to be removed in the major release after, since that will immediately be using a loud ``FutureWarning`` with not much time between deprecation and removal. Instead, a ``DeprecationWarning`` should be used, and the removal should be scheduled for a later major release.
 
 ### Enforcement of deprecations
 
 When one enforces a deprecation, they should:
 - Add an entry in the release notes.
-- Replace the ``.. deprecated::`` directive in the documentation with a ``.. versioncchanged::`` directive.
+- For API changes, replace the ``.. deprecated::`` directive in the documentation with a ``.. versionchanged::`` directive.
 
 ### PDEP-17 History