Fix: typos

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**:
 

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                                             |
 | ------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------ |

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-

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