diff --git a/README.md b/README.md
index fbaee87c9797d1abc2c63dbe8edef02a9c991592..60ecc082d6a438761314c345fcf54a86e1408b47 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,39 @@
# Duniter v2s
-A rewriting of [Duniter](https://duniter.org) based on [Substrate](https://www.substrate.io/) framework.
-
-duniter-v2s is under active development, only a test network called "ÄžDev" is deployed.
+🆙 A rewriting of [Duniter v1](https://duniter.org) in the [Substrate](https://www.substrate.io/) framework.
+
+âš ï¸ Duniter-v2s is under active development.
+
+🚧 A test network called "ĞDev" is deployed, allowing to test wallets and indexers.
+
+<div align="center">
+ <img alt="logov2" src="https://duniter.fr/img/duniterv2.svg" width="128" height="128"/>
+</div>
+
+## Documentation TOC
+
+- [README](./README.md)
+ - [Use](#use)
+ - [Test](#test)
+ - [Contribute](#contribute)
+ - [Structure](#project-structure)
+- [docs](./docs/)
+ - [api](./docs/api/)
+ - [manual](./docs/api/manual.md)
+ - [runtime-calls](./docs/api/runtime-calls.md) the calls you can submit through the RPC API
+ - [dev](./docs/dev/)
+ - [git-conventions](./docs/dev/git-conventions.md)
+ - [launch-a-live-network](./docs/dev/launch-a-live-network.md)
+ - [setup](./docs/dev/setup.md)
+ - [verify-runtime-code](./docs/dev/verify-runtime-code.md)
+ - [weights-benchmarking](./docs/dev/weights-benchmarking.md)
+ - [test](./docs/test/)
+ - [replay-block](./docs/test/replay-block.md)
+ - [user](./docs/user/)
+ - [autocompletion](./docs/user/autocompletion.md)
+ - [build-for-arm](./docs/user/build-for-arm.md)
+ - [rpc](./docs/user/rpc.md)
+ - [smith](./docs/user/smith.md)
## Use
@@ -20,8 +51,8 @@ To go further, read [How to deploy a permanent mirror node on ÄžDev network](./d
### Create your local blockchain
-It can be useful to deploy your local blockchain, for instance to have a controled environement
-to develop/test an application that interact with the blockchain.
+It can be useful to deploy your local blockchain, for instance to have a controlled environement
+to develop/test an application that interacts with the blockchain.
```docker
docker run -it -p9944:9944 duniter/duniter-v2s:v0.1.0 --tmp
@@ -31,9 +62,9 @@ Or use the `docker-compose.yml` at the root of this repository.
#### Control when your local blockchain should produce blocks
-By default, your local blockchain produce a new block every 6 seconds, which is not practical in some cases.
+By default, your local blockchain produces a new block every 6 seconds, which is not practical in some cases.
-You can decide when to produce blocks with the cli option `--sealing`, , there are 2 possible modes:
+You can decide when to produce blocks with the cli option `--sealing` which has two modes:
* `--sealing=instant`: produce a block immediately upon receiving a transaction into the transaction pool
* `--sealing=manual`: produce a block upon receiving an RPC request (method `engine_createBlock`).
@@ -77,7 +108,7 @@ First, complete the [basic setup instructions](./docs/dev/setup.md).
### Build
-NOTE: You must first follow the instructions in the [Setup] section (#setup).
+NOTE: You must first follow the instructions in the [Setup](#setup-your-dev-environment) section.
Use the following command to build the node without launching it:
diff --git a/docs/dev/git-conventions.md b/docs/dev/git-conventions.md
index 74c4207fd436b10d753b7010e552fea3db7e114d..084918cbc2b4e63ffb623955612e3b47e1941255 100644
--- a/docs/dev/git-conventions.md
+++ b/docs/dev/git-conventions.md
@@ -15,10 +15,10 @@ The summary gives an overview of the rules described below. Reading it will help
## Naming commits
-Every commit must follow [conventional commit specification v1.0.0].
+Every commit must comply with [conventional commit specification v1.0.0].
-The commit name hase to be meaningful in the context of commit history reread. It should not make reference to a specific MR or discussion.
-Among other, commit history is used in changlogs and to follow the project progress, that's why it has to be self-explanatory.
+The commit name has to be meaningful in the context of commit history reread. It should not make reference to a specific MR or discussion.
+Among other, commit history is used in changlogs and to track the project progress, that's why it has to be self-explanatory.
If you have a new need, please contact the main developers to add a type together.
## Update strategy
@@ -28,18 +28,13 @@ We only use **rebases**, *merges* are strictly fordbidden !
Every time the `master` branch is updated, you must rebase each of your working branch on it. For each of them:
1. Go on your branch
-2. Run a rebase on master:
+1. Rebase on master with `git rebase master`
+1. If you see conflicts, fix them by editing the sources. Once it is done, you must:
+ 1. commit the files that were in conflict
+ 1. continue the rebase with `git rebase --continue`
+1. Keep doing until you don't have any more conflict after `git rebase --continue`.
- git rebase master
-
-3. If you see conflicts, fix them by editing the sources. Once it is done, you must:
- a. commit the files that were in conflict
- b. continue the rebase with `git rebase --continue`
- c. Do 3. again for each commit that will be in conflict.
-
-4. When you don't have any conflict anymore after `git rebase --continue`, then the rebase succeeded. Then rebase a remaning branch.
-
-To prevent accidental merge commits, we recommend that force the `--ff-only` option on the merge command:
+To prevent accidental merge commits, we recommend to force the `--ff-only` option on the merge command:
git config --global merge.ff only
@@ -58,20 +53,24 @@ any problem with your material.
After complying with the above criteria in your commits, you should check that your branch is up to date with the target branch (`master` in this example). As this branch is moving forward frequently, it is possible that new commits may have occurred while you were working on your branch (named YOUR_BRANCH, here). If this is the case or in case of doubt, to update your branch with respect to `master`, do the following:
- git checkout master # switch to master branch
- git pull # updates the remote branch based on remote
- git checkout YOU_BRANCH # switch back to your branch
- git rebase master # rebase you work on master branch
+```bash
+git checkout master # switch to master branch
+git pull # updates the remote branch based on remote
+git checkout YOU_BRANCH # switch back to your branch
+git rebase master # rebase you work on master branch
+```
In case of conflict during rebase that you can not solve, contact a lead developer telling them the hash of the commit on which YOUR_BRANCH is currently based so they can reproduce the rebase and see the conflicts. While waiting for their answer, you can cancel the rebase and work on YOUR_BRANCH without updating:
- git rebase --abort
+```
+git rebase --abort
+```
It is better to take your time before integrating a new contribution because the history of the master branch cannot be modified: it is a protected branch. Each commit on this branch remains there *ad vitam aeternam* that is why we make sure to keep a clear and understandable commit history.
## Discussion in a merge request
-On Gitlab, a discussion is opened for each merge request. It will allow you to discuss the changes you have made. Feel free to identify someone by writing @pseudo so that they are notified of your request. Don't be impatient, the review of your contribution may take more or less time depending on its content!
+On Gitlab, a discussion is opened for each merge request. It will allow you to discuss the changes you have made. Feel free to tag someone by writing @pseudo so that they are notified of your request. Don't be impatient, the review of your contribution may take more or less time depending on its content!
The general discussion is used to comment on the merge request as a whole, for example to tag a developer for a proofreading request. When it comes to discussing a specific change in the code, you should go to the "Changes" tab of the merge request and comment under the code extract involved. This makes it easier to break down the resolution of problems raised by the merge request via the "comment resolution" feature. Each segment can be marked as resolved, but only the reviewer is allowed to do so!
@@ -81,7 +80,7 @@ When you finished developing, you must compile, run linter and run all tests:
cargo fmt
cargo clippy
- cd tests && npm test
+ cd tests && npm test # FIXME
Then commit everything.
@@ -93,7 +92,7 @@ If you have a pile of commits, use the useful interactive rebase to clean up you
There you can rename the `wip:` commits, you can "fixup" commits that go together, you can rename and re-order commits,...
-After an interactive rebase, your local git history is different that yours in Gitlab, so you need a force push to make it to Gitlab:
+After an interactive rebase, your local git history differs from Gitlab's version, so you need a force push to make it to Gitlab:
git push -f
diff --git a/docs/dev/verify-runtime-code.md b/docs/dev/verify-runtime-code.md
index d99b7f08416e529e958a0e6abc9d56aacc0c4533..6903dcba695103ceab7291e516e116b7ce835e21 100644
--- a/docs/dev/verify-runtime-code.md
+++ b/docs/dev/verify-runtime-code.md
@@ -1,5 +1,7 @@
# Compile the runtime with srtool
+When voting for a runtime upgrade, you should check that the proposed sha256sum actually corresponds to the published code you reviewed. Otherwise, a malicious runtime upgrade could be advertised as a legitimate one.
+
```docker
docker run \
-i \