From 55b233c528da4a6ece3b3a28cc50fa7e298eba05 Mon Sep 17 00:00:00 2001 From: Smoothieewastaken <86610201+Smoothieewastaken@users.noreply.github.com> Date: Mon, 30 Oct 2023 12:51:52 +0545 Subject: [PATCH] docs: Fixed typos (#17749) --- doc/decisions/0010-remove-jail-and-status-api.md | 2 +- doc/decisions/0011-tweak-pr-process.md | 2 +- doc/decisions/0013-tribute-to-talk.md | 6 +++--- doc/how-to-launch-e2e.md | 2 +- doc/patching.md | 2 +- doc/post-mortem.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/decisions/0010-remove-jail-and-status-api.md b/doc/decisions/0010-remove-jail-and-status-api.md index 048729894e..2590047a67 100644 --- a/doc/decisions/0010-remove-jail-and-status-api.md +++ b/doc/decisions/0010-remove-jail-and-status-api.md @@ -18,7 +18,7 @@ While neat in theory, it has some serious downsides: As a result of that, more dynamic/state requiring things (like the live tx detail in `/send` command messages) were very hard to do, so instead of "eating our own dogfood", we decided to side-step the API and implement such things as hard-coded logic in the app, while partly retaining the js code for "easier" things (like parameter declaration). - Needles to say, such efforts produced code of very poor quality, riddling our app with hard-coded "magic" everywhere in the codebase, completly + Needles to say, such efforts produced code of very poor quality, riddling our app with hard-coded "magic" everywhere in the codebase, completely defeating the point of "dogfooding" while still requiring more effort and being much more error prone (no way to unit test jail logic) because of the need to asynchronously communicate with jail for leftover logic in command messages (the parts not hardcoded in app). diff --git a/doc/decisions/0011-tweak-pr-process.md b/doc/decisions/0011-tweak-pr-process.md index 81484eb24f..30ff27e897 100644 --- a/doc/decisions/0011-tweak-pr-process.md +++ b/doc/decisions/0011-tweak-pr-process.md @@ -13,7 +13,7 @@ accepted There was a generally dissatisfaction with our PR flow process from multiple stakeholders, including devs, QA and design. These largely centered around size, speed of integration and quality of PRs. -For more details, please see pain points in the meeting notes held end of February here: https://notes.status.im/C5pj8g7gQOu9Wo8PtDZsMw?edit# as well as the preceeding Discuss thread: https://discuss.status.im/t/better-pull-requests-process/1044 +For more details, please see pain points in the meeting notes held end of February here: https://notes.status.im/C5pj8g7gQOu9Wo8PtDZsMw?edit# as well as the preceding Discuss thread: https://discuss.status.im/t/better-pull-requests-process/1044 Also see conversations in Core Dev Call #12 and #13: https://github.com/status-im/pm/ diff --git a/doc/decisions/0013-tribute-to-talk.md b/doc/decisions/0013-tribute-to-talk.md index 810e96aa4b..744205417a 100644 --- a/doc/decisions/0013-tribute-to-talk.md +++ b/doc/decisions/0013-tribute-to-talk.md @@ -18,7 +18,7 @@ The whitepaper also proposes that the deposit is only forfeited to the recipient Considering: - the absence of efficient ways to perform anonymous transactions (zk-snarks could be used in the future for that) -- the impossibility to prove that a recipient has made an actual reply and not some kind of automated reply (captcha solution was proposed, but wouldn't be pratical until we can use a solution such as swarm feeds that allow users to make free updates to their captcha without on-chain transactions) +- the impossibility to prove that a recipient has made an actual reply and not some kind of automated reply (captcha solution was proposed, but wouldn't be practical until we can use a solution such as swarm feeds that allow users to make free updates to their captcha without on-chain transactions) - the limited time to develop the feature We opted for a solution that: @@ -28,8 +28,8 @@ We opted for a solution that: ## Manifests -Since TtT related informations aren't stored on chain, they need to be stored somewhere else. -For the first iteration of TtT we opted for IPFS, which is already used accross the app for other forms of content, through Infura IPFS gateway. +Since TtT related information aren't stored on chain, they need to be stored somewhere else. +For the first iteration of TtT we opted for IPFS, which is already used across the app for other forms of content, through Infura IPFS gateway. On IPFS we store what we call a ttt manifest, which is a json file with the following format: diff --git a/doc/how-to-launch-e2e.md b/doc/how-to-launch-e2e.md index 2172cd6ec6..66cceee035 100644 --- a/doc/how-to-launch-e2e.md +++ b/doc/how-to-launch-e2e.md @@ -64,7 +64,7 @@ tests (otherwise some PRs could wait their turn of the scheduled Jenkins job til ## Analysing test results (and why test fails to pass) -After automated test run finished test results could be found in GH comment (if the test suite ran agaist PR) and TestRail. There are two states of the test: Passed and Failed. Test failure happens when certain condition of test step has not met or automated test can not proceed execution because it can not find the respective element on screen it expects should be there. +After automated test run finished test results could be found in GH comment (if the test suite ran against PR) and TestRail. There are two states of the test: Passed and Failed. Test failure happens when certain condition of test step has not met or automated test can not proceed execution because it can not find the respective element on screen it expects should be there. Several examples of when test fails to succeed: diff --git a/doc/patching.md b/doc/patching.md index 1e27a58e6d..f0de38639d 100644 --- a/doc/patching.md +++ b/doc/patching.md @@ -1,7 +1,7 @@ # Patching ## Libraries -If 3rd party library has an issue and fix is not yet released (or we can't switch to a new release), we use forks. Fix should be commited to the fork, tagged and referenced from package.json. +If 3rd party library has an issue and fix is not yet released (or we can't switch to a new release), we use forks. Fix should be committed to the fork, tagged and referenced from package.json. Example: [`react-native-hole-view`](https://github.com/status-im/react-native-hole-view#refs/tags/v2.1.1-status) diff --git a/doc/post-mortem.md b/doc/post-mortem.md index c9ea03532c..b88e496506 100644 --- a/doc/post-mortem.md +++ b/doc/post-mortem.md @@ -13,7 +13,7 @@ QA process was focused on account creation and login with keycard, and this bug ## Resolution process -- the commit was reverted locally by the developer which fixed the issue localy and confirmed the faulty commit +- the commit was reverted locally by the developer which fixed the issue locally and confirmed the faulty commit - the bug was only reproducible on iOS which strongly hinted at a potential issue with native code - the missing method was not the origin of the problem but was found at this point and further analysis lead to the shadowing error