diff --git a/pep-0620.rst b/pep-0620.rst
index 1faaf384b..18d47c186 100644
--- a/pep-0620.rst
+++ b/pep-0620.rst
@@ -16,15 +16,15 @@ Once most implementation details will be hidden, evolution of CPython
 internals would be less limited by C API backward compatibility issues.
 It will be way easier to add new features.
 
-It becomes possible to experiment in CPython with more advanced
-optimizations than just micro-optimizations, like tagged pointers.
+It becomes possible to experiment with more advanced optimizations in
+CPython than just micro-optimizations, like tagged pointers.
 
 Define a process to reduce the number of broken C extensions.
 
 The implementation of this PEP is expected to be done carefully over
 multiple Python versions. It already started in Python 3.7 and most
 changes are already completed. The `Process to reduce the number of
-broken C extensions`_ didactes the rhythm.
+broken C extensions`_ dictates the rhythm.
 
 
 Motivation
@@ -150,10 +150,10 @@ Hide implementation details
 
 Hiding implementation details from the C API has multiple advantages:
 
-* It becomes possible to experiment in CPython more with advanced
-  optimizations than just micro-optimizations. For example, tagged
-  pointers, and replace the garbage collector with a tracing garbage
-  collector which can move objects.
+* It becomes possible to experiment with more advanced optimizations in
+  CPython than just micro-optimizations. For example, tagged pointers,
+  and replace the garbage collector with a tracing garbage collector
+  which can move objects.
 * Adding new features in CPython becomes easier.
 * PyPy should be able to avoid conversions to CPython objects in more
   cases: keep efficient PyPy objects.
@@ -363,7 +363,7 @@ is exposed in the C API. All structures must become opaque, since they
 
 Making ``PyObject`` fully opaque requires converting ``Py_INCREF()`` and
 ``Py_DECREF()`` macros to function calls. This change has an impact on
-performance. It is likely to be one of the very last change when making
+performance. It is likely to be one of the very last changes when making
 structures opaque.
 
 Making ``PyTypeObject`` structure opaque breaks C extensions declaring
@@ -529,8 +529,8 @@ https://github.com/pythoncapi/pythoncapi_compat
 Process to reduce the number of broken C extensions
 ===================================================
 
-Process to reduce the number of broken C extensions when introduce C API
-incompatible changes listed in this PEP:
+Process to reduce the number of broken C extensions when introducing C
+API incompatible changes listed in this PEP:
 
 * Estimate how many popular C extensions are affected by the
   incompatible change.
@@ -545,10 +545,10 @@ incompatible changes listed in this PEP:
   C extensions maintainers to prepare their project for the next Python.
 * If the change breaks too many projects, reverting the change should be
   discussed, taking in account the number of broken packages, their
-  importance in the Python commmunity, and the importance of the change.
+  importance in the Python community, and the importance of the change.
 
 The coordination usually means reporting issues to the projects, or even
-propose changes. It does not require waiting for a new release including
+proposing changes. It does not require waiting for a new release including
 fixes for every broken project.
 
 Since more and more C extensions are written using Cython, rather
@@ -579,7 +579,7 @@ Version History
 
 * Version 3, June 2020: PEP rewritten from scratch. Python now
   distributes a new ``pythoncapi_compat.h`` header and a process is
-  defined to reduce the number of broken C extensions when introduce C
+  defined to reduce the number of broken C extensions when introducing C
   API incompatible changes listed in this PEP.
 * Version 2, April 2020:
   `PEP: Modify the C API to hide implementation details