From 2cd63e21e1a00ede39703107d158c5c67f8b8624 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Mon, 5 Sep 2022 09:34:19 +0200 Subject: [PATCH 1/4] Fix: typo in quote Fix: typo in quote --- contribution-guidelines/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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- From 811460413d775e277561882e9f9561edcd4f1844 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Mon, 5 Sep 2022 09:37:26 +0200 Subject: [PATCH 2/4] Fix: typo Fix: typo --- .../general-dev.-workflow/task-tracking-and-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 | | ------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------ | From 7ace10adc6e3b8f794264deb29fadabc8b1ccf94 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Mon, 5 Sep 2022 09:42:52 +0200 Subject: [PATCH 3/4] Fix: typo Fix: typo --- contribution-guidelines/smart-contract-workflow/rab.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 From 72d8c4c1c8ed189bd21c0e395d46f2d6f47dbac0 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Mon, 5 Sep 2022 09:44:48 +0200 Subject: [PATCH 4/4] Fix: typos Fix: typos --- contribution-guidelines/code-style-and-guidelines/solidity.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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**: