diff --git a/contribution-guidelines/code-style-and-guidelines/solidity.md b/contribution-guidelines/code-style-and-guidelines/solidity.md
index 2c9d7d7..0222835 100644
--- a/contribution-guidelines/code-style-and-guidelines/solidity.md
+++ b/contribution-guidelines/code-style-and-guidelines/solidity.md
@@ -24,7 +24,7 @@ If a function is **not** `O(1)` , the first line of the `@dev` part of the ENSF
 
 #### External Trust
 
-For functions that make an external call with enough gas for re-entry, not `send` or `transfer`, specify **"UN/TRUSTED."** at the end of the `@dev` part of the ENSF comment. This tells readers wether the external call receiver is trusted or not, i.e. the code it executes is controlled.
+For functions that make an external call with enough gas for re-entry, not `send` or `transfer`, specify **"UN/TRUSTED."** at the end of the `@dev` part of the ENSF comment. This tells readers whether the external call receiver is trusted or not, i.e. the code it executes is controlled.
 
 {% hint style="danger" %}
 Note that specifying a **contract type** for a variable **does not guarantee** that it will reference a contract of that **type** as any address can be coerced into any contract, and vice-versa.
@@ -51,7 +51,7 @@ Traditional back ends do most of the heavy lifting for the front end, because co
 Abstractions can be made to make front end developers' lives easier. Our [archon](https://github.com/kleros/archon) does just that for ERC 792 contracts.
 {% endhint %}
 
-This and the security risks of smart contracts that interact with other smart contracts with complex and stateful interdependencies requires that we take a unique approach and mindset when developing smart contracts. Here are some general guidelines:
+This and the security risks of smart contracts that interact with other smart contracts with complex and stateful interdependencies require that we take a unique approach and mindset when developing smart contracts. Here are some general guidelines:
 
 * If possible, i.e. does not lead to a significant increase in computation, externally called functions should follow this **3-step pattern**:
 
diff --git a/contribution-guidelines/general-dev.-workflow/task-tracking-and-lifecycle.md b/contribution-guidelines/general-dev.-workflow/task-tracking-and-lifecycle.md
index a1ac933..8f8cc79 100644
--- a/contribution-guidelines/general-dev.-workflow/task-tracking-and-lifecycle.md
+++ b/contribution-guidelines/general-dev.-workflow/task-tracking-and-lifecycle.md
@@ -10,7 +10,7 @@ description: Our methodology for keeping track of development work.
 See [Git Code Style & Guidelines](../code-style-and-guidelines/git.md) for our message and branch names style and guidelines.
 {% endhint %}
 
-We try to keep the number of tools we use to a minimum for simplicity and ease of on-boarding. The new features of Github make it possible to keep most of the project management next to the code, and this is our approach:
+We try to keep the number of tools we use to a minimum for simplicity and ease of onboarding. The new features of Github make it possible to keep most of the project management next to the code, and this is our approach:
 
 | Issues                                                  | Projects                               | Milestones                                             |
 | ------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------ |
diff --git a/contribution-guidelines/overview.md b/contribution-guidelines/overview.md
index ea88bb9..d43c4c4 100644
--- a/contribution-guidelines/overview.md
+++ b/contribution-guidelines/overview.md
@@ -46,6 +46,6 @@ This site is maintained at [github.com/kleros/CONTRIBUTING.md](https://github.co
 
 The rules in this guide are meant to be followed as much as possible, but should not override common sense.
 
-> The golden rules is that there are no golden rules.
+> The golden rule is that there are no golden rules.
 >
 > \-George Bernard Shaw-
diff --git a/contribution-guidelines/smart-contract-workflow/rab.md b/contribution-guidelines/smart-contract-workflow/rab.md
index c70d469..3acc574 100644
--- a/contribution-guidelines/smart-contract-workflow/rab.md
+++ b/contribution-guidelines/smart-contract-workflow/rab.md
@@ -19,7 +19,7 @@ In the context of reviews, audits and bounties, findings have to be pointed out
 
 Note that this is the same risk rating model used by the [Ethereum Bounty Program](https://bounty.ethereum.org/).
 
-In addition to the severity classification, emphasis should be put in writing clear descriptions, adding tests and instructions for facilitating reproduceability and including potential fixes if known.
+In addition to the severity classification, emphasis should be put in writing clear descriptions, adding tests and instructions for facilitating reproducibility and including potential fixes if known.
 
 ## RAB Pragmas