docs: Fixed typos (#17749)

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

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/
 

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:
 

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:
 

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)
 

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