matplotlib
diff --git a/‎doc/api/prev_api_changes/api_changes_0.54.rst
Copy file name to clipboardExpand all lines: doc/api/prev_api_changes/api_changes_0.54.rst
+1-1Lines changed: 1 addition & 1 deletion b/‎doc/api/prev_api_changes/api_changes_0.54.rst
Copy file name to clipboardExpand all lines: doc/api/prev_api_changes/api_changes_0.54.rst
+1-1Lines changed: 1 addition & 1 deletion
diff --git a/‎doc/devel/color_changes.rst
Copy file name to clipboardExpand all lines: doc/devel/color_changes.rst
+2-2Lines changed: 2 additions & 2 deletions b/‎doc/devel/color_changes.rst
Copy file name to clipboardExpand all lines: doc/devel/color_changes.rst
+2-2Lines changed: 2 additions & 2 deletions
diff --git a/‎doc/devel/contributing.rst
Copy file name to clipboardExpand all lines: doc/devel/contributing.rst
+1-1Lines changed: 1 addition & 1 deletion b/‎doc/devel/contributing.rst
Copy file name to clipboardExpand all lines: doc/devel/contributing.rst
+1-1Lines changed: 1 addition & 1 deletion
@@ -30,7 +30,7 @@ The original pcolor and scatter functions are retained as
 pcolor_classic and scatter_classic.
 
 The return value from pcolor is a PolyCollection.  Most of the
-propertes that are available on rectangles or other patches are also
+properties that are available on rectangles or other patches are also
 available on PolyCollections, e.g., you can say::
 
   c = scatter(blah, blah)
 
@@ -64,11 +64,11 @@ Default Scatter Colormap
 ------------------------
 
 For heat-map like applications it can be desirable to cover as much of
-the luminence scale as possible, however when color mapping markers,
+the luminance scale as possible, however when color mapping markers,
 having markers too close to white can be a problem.  For that reason
 we propose using a different (but maybe related) color map to the
 heat map for marker-based.  The design parameters are the same as
-above, only with a more limited luminence variation.
+above, only with a more limited luminance variation.
 
 
 Example script
 
@@ -405,7 +405,7 @@ on, use the key/value keyword args in the function definition rather
 than the ``**kwargs`` idiom.
 
 In some cases, you may want to consume some keys in the local
-function, and let others pass through.  Instead of poping arguments to
+function, and let others pass through.  Instead of popping arguments to
 use off ``**kwargs``, specify them as keyword-only arguments to the local
 function.  This makes it obvious at a glance which arguments will be
 consumed in the function.  For example, in