diff --git a/docs/migration-guide-v0.1.0.md b/docs/migration-guide-v0.1.0.md
index e88e498..c670ab2 100644
--- a/docs/migration-guide-v0.1.0.md
+++ b/docs/migration-guide-v0.1.0.md
@@ -96,7 +96,7 @@ ds = xr.open_dataset(
 
 #### Example 1: Global dataset at fixed scale
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 ds = xr.open_dataset(
     'ECMWF/ERA5_LAND/MONTHLY_AGGR',
@@ -128,7 +128,7 @@ ds = xr.open_dataset(
 
 #### Example 2: Regional dataset with EE geometry
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 import ee
 
@@ -167,7 +167,7 @@ ds = xr.open_dataset(
 
 #### Example 3: Using source resolution for a custom area
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 # You had to manually determine the scale from the dataset
 ds = xr.open_dataset(
@@ -215,7 +215,7 @@ Xee v0.1.0 outputs dimensions in `[time, y, x]` order (matching CF conventions a
 
 #### Plotting
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 # Required transpose for correct visualization
 ds['temperature_2m'].isel(time=0).transpose().plot()
@@ -231,7 +231,7 @@ ds['temperature_2m'].isel(time=0).plot()
 
 Many geospatial libraries expect `[time, y, x]` ordering. You may have been using `.transpose()` to accommodate this.
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 # Had to transpose for libraries expecting [time, y, x]
 data_array = ds['temperature_2m'].transpose('time', 'y', 'x')
@@ -249,7 +249,7 @@ export_to_geotiff(data_array)
 
 If you have code that explicitly references dimension positions, update it:
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 # Dimensions were [time, x, y]
 time_dim, x_dim, y_dim = ds['temperature_2m'].dims
@@ -280,7 +280,7 @@ time_length = ds.sizes['time']
 
 ### Pattern 1: Simple global analysis
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 import ee
 import xarray as xr
@@ -323,7 +323,7 @@ mean_temp.plot()  # No transpose needed
 
 ### Pattern 2: Regional analysis with preprocessing
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 import ee
 import xarray as xr
@@ -384,7 +384,7 @@ ds = xr.open_dataset(collection, engine='ee', **grid_params)
 
 ### Pattern 3: Export workflows
 
-**Before (v0.1.0):**
+**Before (v0.0.x):**
 ```python
 import xarray as xr
 
diff --git a/docs/why-xee.md b/docs/why-xee.md
index c9db755..8d41427 100644
--- a/docs/why-xee.md
+++ b/docs/why-xee.md
@@ -76,7 +76,7 @@ Differences:
 -   **Quota vs No Quota**: Since Earth Engine is API based, there are quota
     restrictions that limit IO, namely a 100 QPS limit on data requests. Readers
     all need to be authenticated and tied to a GCP project quota. Zarr, on the
-    other hand, has a lower level access pattern. Reading is delegating to basic
+    other hand, has a lower level access pattern. Reading is delegated to basic
     permissions on cloud buckets.
 -   **On the fly vs up-front data shaping**: In Zarr, the representation of data
     at rest fundamentally influences performance at query time. For this reason,
@@ -87,7 +87,7 @@ Differences:
     server-side), users are free to request the resolution and projection of the
     data during dataset open. Similarly, while Earth Engine's internal dataset
     does fit an internal chunking scheme, chunking schemes are a lot more
-    fungibile.
+    fungible.
 
-We hope that this comparison provides the user of a set of useful precedents for
+We hope that this comparison provides the user with a set of useful precedents for
 working with cloud-based datasets.