docs: Fixed typos (#17749)

This commit is contained in:
Smoothieewastaken 2023-10-30 12:51:52 +05:45 committed by GitHub
parent 68ad4fe086
commit 55b233c528
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 8 additions and 8 deletions

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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