docs/dev/beginner-walkthrough.md

+# Beginner walkthrough
+
+This is a beginner tutorial for those who do not have a previous experience with Rust ecosystem or need guidance to get familiar with Duniter v2s project. You'll need a development machine with an internet connection, at least **20 GB of free storage**, and **an hour or two** depending on your computing power.
+
+This walkthrough is based on the following video (french), don't hesitate to record an english voiceover if you feel so.
+
+[![preview](https://tube.p2p.legal/lazy-static/previews/654006dc-66c0-4e37-a32f-b7b5a1c13213.jpg)](https://tube.p2p.legal/w/n4TXxQ4SqxzpHPY4TNMXFu)
+
+> video walkthrough on peertube https://tube.p2p.legal/w/n4TXxQ4SqxzpHPY4TNMXFu
+
+## Requirements
+
+If you are on a debian based system, you can install the required packages with:
+
+```bash
+sudo apt install cmake pkg-config libssl-dev git build-essential clang libclang-dev curl protobuf-compiler
+```
+
+Else, look at the corresponding section in the [system setup documentation](./setup.md).
+
+Rust recommended installation method is through the rustup script that you can run with:
+
+```bash
+curl https://sh.rustup.rs -sSf | sh
+```
+
+If you reopen your terminal, it will give you access to the `rustup`,  `rustc` and `cargo` commands. You can then install the required Rust toolchains with:
+
+```bash
+rustup default stable
+rustup update nightly
+rustup update stable
+rustup target add wasm32-unknown-unknown --toolchain nightly
+```
+
+This can take about **2 minutes**.
+
+## Build project
+
+After cloning wherever you want the `duniter-v2s` repo with:
+
+```bash
+git clone https://git.duniter.org/nodes/rust/duniter-v2s.git
+```
+
+you can go to the root folder and build the substrate client and default runtime with:
+
+```bash
+cargo build
+```
+
+This will take about **2 minutes** to download dependencies plus between 5 and **15 minutes** to build in debug mode depending on the power of your processor. At this point, you built the *substrate client* (a kind of "shell" in which lies the runtime) and the default *runtime* itself. You can run a local blockchain with:
+
+```bash
+cargo run -- --dev --tmp # here, --dev means --chain=dev which selects the gdev runtime
+```
+
+When you see the logs, the blockchain is running and you can connect to it with polkadotjs app: [https://polkadot.js.org/apps/?rpc=ws://127.0.0.1:9944](https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944). You should see blocks being added every 6 seconds. You can use Alice, Bob, etc test accounts to submit extrinsics.
+
+## Autocompletion
+
+When using Duniter commands, you will benefit a lot from commands autocompletion. This can be achieved by following [autocompletion documentation](../user/autocompletion.md) for you shell. If you use bash the commands are:
+
+```bash
+# create local dir to store completion script
+mkdir -p ~/.local/share/duniter
+# export the bash completion file
+cargo run -- completion --generator bash > ~/.local/share/duniter/completion.bash
+# add the following line to your ~/.bashrc to automatically load completion on startup
+[[ -f $HOME/.local/share/duniter/completion.bash ]] && source $HOME/.local/share/duniter/completion.bash
+```
+
+You will then benefit from completion using `<Tab>` key and `*`.
+
+## End-to-end tests using cucumber
+
+Cucumber end2end tests are a good way to dive in Duniter's business procedure. They work by spawning a local blockchain and submitting extrinsics to it. You can build and run the cucumber tests by running:
+
+```bash
+cargo cucumber
+```
+
+which should take about **4 minutes** to build and run the tests. A highly detailed documentation about the end2end tests is available [in the dedicated folder](../../end2end-tests/README.md), you will learn how to read and modify the tests.
+
+## Get in touch with us
+
+Wether you are stuck and need help or have sucessfully completed this tutorial, don't hesitate to get in touch with us on the Duniter forum! If you found this walkthrough useful, please 🙏 let us know on the [walkthrough topic](https://forum.duniter.org/t/contribuer-a-duniter-tutoriel-video/9770) on the forum 😊.
\ No newline at end of file

docs/dev/compilation.md

+# Compilation
+
+Duniter is compiled using the Rust compiler. For a general overview, refer to the [Rustc Dev Guide](https://rustc-dev-guide.rust-lang.org/overview.html).
+
+Substrate and Duniter provide a set of features enabling or disabling parts of the code using conditional compilation. More information on conditional compilation can be found [here](https://doc.rust-lang.org/reference/conditional-compilation.html), or by enabling or disabling compilation of packages. Below is a list of all available features:
+
+## External
+
+- **runtime-benchmarks**: Compiles the runtime with benchmarks for extrinsics benchmarking.
+- **try-runtime**: Compiles the runtime for tests and verifies operations in a simulated environment.
+- **std**: Enables the Rust standard library.
+
+## Duniter
+
+- **gdev**: Sets `gdev-runtime` and `std` used to build the development chain.
+- **gtest**: Sets `gtest-runtime` and `std` used to build the test chain.
+- **g1**: Sets `g1-runtime` and `std` used to build the production chain.
+- **constant-fees**: Uses a constant and predictable weight-to-fee conversion only for testing.
+- **embed**: Enables hardcoded live chainspecs loaded from "../specs/gtest-raw.json" file.
+- **native**: Compiles the runtime into native-platform executable only for debugging purposes.
+
+Note: By default, Duniter will be compiled using the `gdev` feature and including the compilation of the distance oracle. Since the three Duniter chains are mutually exclusive, it is mandatory to disable the default feature to compile `gtest` and `g1` as follows:
+
+- `cargo build --no-default-features --features gtest`
+- `cargo build --no-default-features --features g1`
+- `cargo build --no-default-features -p distance-oracle --features std`

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:
 
+```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
+```
 
 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,8 @@ When you finished developing, you must compile, run linter and run all tests:
 
     cargo fmt
     cargo clippy
-    cd tests && npm test
+    cargo tu
+    cargo cucumber
 
 Then commit everything.
 
@@ -93,7 +93,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
 

docs/test/replay-block.md → docs/dev/replay-block.md

 # How to replay a block
 
-You can use `try-runtime` subcommand to replay a block against a real satte from a live network.
+WARN: try-runtime is not properly implemented
+
+You can use `try-runtime` subcommand to replay a block against a real state from a live network.
 
 1. Checkout the git tag of the runtime version at the block you want to replay
 2. Build duniter with feature `try-runtime`: `cargo build --features try-runtime`
@@ -9,13 +11,13 @@ You can use `try-runtime` subcommand to replay a block against a real satte from
 5. Replay the block a first time to get the state:
 
 ```
-duniter try-runtime --exectuion=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 live -s tmp/snapshot1 -u ws://localhost:9944
+duniter try-runtime --execution=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 live -s tmp/snapshot1 -u ws://localhost:9944
 ```
 
 6. Then, replay the block as many times as you need against your local snapshot:
 
 ```
-duniter try-runtime --exectuion=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 --block-ws-uri ws://localhost:9944 snap -s tmp/snapshot1
+duniter try-runtime --execution=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 --block-ws-uri ws://localhost:9944 snap -s tmp/snapshot1
 ```
 
 try-runtime does not allow (for now) to store the block locally, only the storage can be stored.