WIP grammar fixes

CONTRIBUTING.md

@@ -52,7 +52,7 @@ for i in $(ls -d .changelog/*/*/); do basename "$i"; done | sort | uniq
 
 The Namada SDK is exposed to any developer building upon Namada. Thus, any change made to a public facing function is a breaking change, and therefore should be documented in the Changelog under the `SDK` section.
 
-The message should outline the exact API change, along with a small section describing *how* and *why* the component was change. This should give motivation and context to any developer building upon Namada on how they can update their code to the next version.
+The message should outline the exact API change, along with a small section describing *how* and *why* the component was changed. This should give motivation and context to any developer building upon Namada on how they can update their code to the next version.
 
 ## Development priorities
 

documentation/dev/src/explore/design/ledger/storage/data-schema.md

@@ -4,7 +4,7 @@ At high level, all the data in the [accounts' dynamic
 sub-spaces](../accounts.md#dynamic-storage-sub-space) is just keys associated with
 arbitrary bytes and intents are just wrapper around arbitrary data. To help the
 processes that read and write this data (transactions, validity predicates,
-matchmaker) interpret it and implement interesting functionality on top it, the
+matchmaker) interpret it and implement interesting functionality on top of it, the
 ledger could provide a way to describe the schema of the data.
 
 For storage data encoding, we're currently using the borsh library, which