Improve Docs Readability

DEVELOPMENT.md

@@ -30,7 +30,7 @@ to only run both non-feature-specific tests and tests for json.
 
 ## Merging
 
-We currently do not have maintainance versions and thus only PR and merge to `main`.
+We currently do not have maintenance versions and thus only PR and merge to `main`.
 
 We use labels to build a changelog - it is very important to label issues and/or PRs
 accordingly. Because our changelog can contain both issues and PRs, when a PR closes
@@ -39,17 +39,17 @@ the author (credits).
 
 Summary:
 * pull requests with both backward-incompatible changes and new 
-  features/enchancements MUST close at least one issue (the one
+  features/enhancements MUST close at least one issue (the one
   documenting the backward-incompatible change)
 * Every other pull request MAY close one issue
 
 issues are only used to document situations whose a single PR adds two entries to
-the changelog (e.g. a backward incompatible change + an new enchancement).
+the changelog (e.g. a backward incompatible change + a new enhancement).
 
 Merging a PR to main has the following checklist:
 
 1. Does it close an issue? If yes, add the label `no-changelog` to the issue.
-2. Label the PR accordingly (`Testing`, `Documentation`, `Enchancement`, `Feature`, `Bug`)
+2. Label the PR accordingly (`Testing`, `Documentation`, `Enhancement`, `Feature`, `Bug`)
 3. If the PR is backward incompatible:
     1. create a new issue labeled `backward-incompatible` with what changed and how to migrate
        from the old API to the new API

README.md

@@ -105,7 +105,7 @@ Design documents about each of the parts of this repo are available on their res
 
 ### Any plans to merge with the Apache Arrow project?
 
-Maybe. The primary reason to have this repo and crate is to be able to propotype
+Maybe. The primary reason to have this repo and crate is to be able to prototype
 and mature using a fundamentally different design based on a transmute-free
 implementation. This requires breaking backward compatibility and loss of
 features that is impossible to achieve on the Arrow repo.

guide/src/io/csv_reader.md

@@ -32,7 +32,7 @@ thereby maximizing IO throughput. The example below shows how to do just that:
 
 ## Async
 
-This crate also supports reading from a CSV asyncronously through the `csv-async` crate.
+This crate also supports reading from a CSV asynchronously through the `csv-async` crate.
 The example below demonstrates this:
 
 ```rust

guide/src/io/parquet_read.md

@@ -77,8 +77,8 @@ When a logical type is defined, we use it as follows:
 | ByteArray         | Decimal           | Decimal       |
 | FixedLenByteArray | Decimal           | Decimal       |
 
-When a a logical type is not defined but a converted type is defined, we use
-the equivalent convertion as above, mutatis mutandis.
+When a logical type is not defined but a converted type is defined, we use
+the equivalent conversion as above, mutatis mutandis.
 
 When neither is defined, we fall back to the physical representation:
 

src/array/README.md

@@ -44,7 +44,7 @@ This document describes the overall design of this module.
 
 * An array MUST have a `offset: usize` measuring the number of slots that the array is currently offsetted by if the specification requires.
 
-* An array MUST implement `fn slice(&self, offset: usize, length: usize) -> Self` that returns an offseted and/or truncated clone of the array. This function MUST increase the array's offset if it exists.
+* An array MUST implement `fn slice(&self, offset: usize, length: usize) -> Self` that returns an offsetted and/or truncated clone of the array. This function MUST increase the array's offset if it exists.
 
 * Conversely, `offset` MUST only be changed by `slice`.