diff --git a/docs/008/voting.rst b/docs/008/voting.rst
index 77e00d6654e98c43b0a97f115d50daab31bd3855..86a2f5cc1cd592b6e15526d386c58d5f5c1b4b35 100644
--- a/docs/008/voting.rst
+++ b/docs/008/voting.rst
@@ -71,7 +71,7 @@ the current participation with the following coefficients::
   newQ = oldQ * 8/10 + participation * 2/10
 
 More details can be found in the file
-``src/proto_008_PtEdo2Zk/lib_protocol/amendment.ml``.
+:src:`src/proto_008_PtEdo2Zk/lib_protocol/amendment.ml`.
 
 Operations
 ----------
@@ -96,11 +96,11 @@ maximum number of proposals for that delegate.
 However duplicates from the same delegate are not tallied at the end
 of the proposal period.
 
-For example, a delegate submits a proposals operation for protocol A
+For example, a delegate submits a ``proposals`` operation for protocols A
 and B early in the proposal period, later a new protocol C is revealed
-and the delegate submits another proposals operation for protocol B
+and the delegate submits another ``proposals`` operation for protocols B
 and C.
-The list of submissions that will be tallied is [A,B,C] and the
+The list of submissions that will be tallied is [A,B,C].
 
 A ballot operation can only be submitted during one of the voting
 periods, and only once per period.
@@ -120,7 +120,7 @@ The pass vote allows a delegate to not influence a vote but still
 allowing it to reach quorum.
 
 More details can be found, as for all operations, in
-``src/proto_008_PtEdo2Zk/lib_protocol/operation_repr.ml``.
+:src:`src/proto_008_PtEdo2Zk/lib_protocol/operation_repr.ml`.
 The binary format is described by ``tezos-client describe unsigned
 operation``.
 
diff --git a/docs/009/voting.rst b/docs/009/voting.rst
index 32c0c8b0cc4e733b806d27745ed92121c16a6e5f..a66f180b3729f6ba8dc0dd893db0e4e8b8fe6a25 100644
--- a/docs/009/voting.rst
+++ b/docs/009/voting.rst
@@ -71,7 +71,7 @@ the current participation with the following coefficients::
   newQ = oldQ * 8/10 + participation * 2/10
 
 More details can be found in the file
-``src/proto_009_PsFLoren/lib_protocol/amendment.ml``.
+:src:`src/proto_009_PsFLoren/lib_protocol/amendment.ml`.
 
 Operations
 ----------
@@ -96,11 +96,11 @@ maximum number of proposals for that delegate.
 However duplicates from the same delegate are not tallied at the end
 of the proposal period.
 
-For example, a delegate submits a proposals operation for protocol A
+For example, a delegate submits a ``proposals`` operation for protocols A
 and B early in the proposal period, later a new protocol C is revealed
-and the delegate submits another proposals operation for protocol B
+and the delegate submits another ``proposals`` operation for protocols B
 and C.
-The list of submissions that will be tallied is [A,B,C] and the
+The list of submissions that will be tallied is [A,B,C].
 
 A ballot operation can only be submitted during one of the voting
 periods, and only once per period.
@@ -120,7 +120,7 @@ The pass vote allows a delegate to not influence a vote but still
 allowing it to reach quorum.
 
 More details can be found, as for all operations, in
-``src/proto_009_PsFLoren/lib_protocol/operation_repr.ml``.
+:src:`src/proto_009_PsFLoren/lib_protocol/operation_repr.ml`.
 The binary format is described by ``tezos-client describe unsigned
 operation``.
 
diff --git a/docs/404.html b/docs/404.html
index f03eef87c10ad3cce56722d14b3a4b1c997d8bc0..7756d3ba29c7a789058403b776c87e2b8376734c 100644
--- a/docs/404.html
+++ b/docs/404.html
@@ -77,7 +77,7 @@
     <hr>
     <p>The resource that you are attempting to access does not exist or you don't have the necessary permissions to view it.</p>
      <p>Make sure the address is correct and that the page hasn't moved.</p>
-     <p>Please write to <a href="mailto:contact@nomadic-labs.com">contact@nomadic-labs.com</a> if you think this is a mistake.</p>
+     <p>Please consider creating a new <a href="https://gitlab.com/tezos/tezos/-/issues">Tezos/tezos issue</a> if you think this is a mistake.</p>
     <a href="javascript:history.back()" class="js-go-back go-back">Go back</a>
   </div>
   <script>
diff --git a/docs/README.rst b/docs/README.rst
index dbc46bbfe45e7198b26b5543ca975546fbd0a603..9a7b5fad26351a76b55b07c99d0cf14000459997 100644
--- a/docs/README.rst
+++ b/docs/README.rst
@@ -52,22 +52,7 @@ reStructuredText is the default plaintext markup language used by
 `Sphinx <https://www.sphinx-doc.org/>`_, which
 is the tool used to compile this format into plain web pages in HTML format.
 
-For the RST syntax, see the `Sphinx RST primer <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html>`_.
-
-Line breaking
--------------
-
-When writing documentation in text formats such as RST, it is not required to respect a maximal line width, such as 80 columns.
-Therefore, you may choose between the different line breaking policies your text editor proposes.
-However, you should be aware that file comparison tools such as ``diff`` tend to output large differences for a paragraph that has been reformatted after only a small change in one phrase.
-Also, reviewing tools such as the one in the GitLab user interface associate comments and change suggestions to lines, while these comments and suggestions are usually logically associated to whole phrases.
-
-For such reasons:
-
-- Some contributors use one line per complete phrase, which allows to make rephrasing suggestions more easily in ``gitlab``, associated to this (possibly long) line; and which allows ``diff`` to isolate modified phrases, instead of showing the whole container paragraph as modified.
-- Other contributors, whose editor breaks lines at a fixed width, introduce an extra line break at the end of each phrase. This also allows ``diff`` to isolate modified phrases.
-
-Thus, you may choose your own formatting style, while tolerating different styles from other contributors.
+For the RST syntax, see the `Sphinx RST primer <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html>`_ and also the `Sphinx extensions`_ below.
 
 Sphinx extensions
 -----------------
@@ -101,6 +86,63 @@ Some ad-hoc reference kinds are supported.
   and commit ranges. This is implemented in
   `docs/_extensions/gitlab_custom_role.py`.
 
+Style guidelines
+----------------
+
+Currently there are no enforced guidelines about the style in writing documentation.
+In particular, the choice of American, British, Canadian, ... English (alphabetical, non-exhaustive list!) is up to each contributor.
+So is the capitalization convention of section names, and other typesetting aspects.
+The focus should be on the contents: on logical structure of documents, on uniform use of terms, on avoiding incoherencies between pages, and so on.
+
+However, when adding a new page or modifying an existing one, you should check that your text displays correctly and introduces no new problems.
+For that, you should build the documentation (by running ``make`` in the ``docs`` directory), address any new error message, and check the generated pages (`docs/_build/index.html`) in a browser.
+
+Links
+~~~~
+
++When introducing cross-references between documentation pages as well as references to external resources, please consider using the most appropriate kind of link:
+
+- When referring to a whole documentation page, you may use a ``:doc:`` role instead of introducing a label at the start of the page.
+  Indeed, labels incur an overhead, especially when pages get duplicated for different protocol versions.
+- When referring to an artifact in the code repository (source file, commit, etc.), you may use an appropriate custom or GitLab role (see `Sphinx extensions`_) instead of a plain HTML link.
+  Indeed, specific roles are checked for correctness more effectively and more efficiently than HTML links.
+
+Line breaking
+~~~~~~~~~~~~~
+
+When writing documentation in text formats such as RST, it is not required to respect a maximal line width, such as 80 columns.
+Therefore, you may choose between the different line breaking policies your text editor proposes.
+However, you should be aware that file comparison tools such as ``diff`` tend to output large differences for a paragraph that has been reformatted after only a small change in one phrase.
+Also, reviewing tools such as the one in the GitLab user interface associate comments and change suggestions to lines, while these comments and suggestions are usually logically associated with whole phrases.
+
+For such reasons:
+
+- Some contributors use one line per complete phrase, which allows to make rephrasing suggestions more easily in ``gitlab``, associated to this (possibly long) line; and which allows ``diff`` to isolate modified phrases, instead of showing the whole container paragraph as modified.
+- Other contributors, whose editor breaks lines at a fixed width, introduce an extra line break at the end of each phrase. This also allows ``diff`` to isolate modified phrases.
+
+Thus, you may choose your own formatting style, while tolerating different styles from other contributors.
+
+
+Writing executable documentation
+--------------------------------
+
+When you are writing documentation containing executable parts, such as sequences of instructions to install, configure, or launch some tool, there is sometimes a better way than copying those instructions from a terminal (where you supposedly tried them before!) to a documentation page.
+This better way is to write "executable documentation".
+The idea is to write such executable scripts separated from the documentation, and to automatically copy them in the documentation whenever it is (re)generated.
+Executable documentation allows one to test those scripts, e.g. in CI (continuous integration), ensuring they work and are up to date with the code and with its environment.
+
+Typically, Tezos installation scripts not only have to evolve with the Tezos codebase, but also with various other evolving resources, such as OPAM packages, package managers, Linux distrbutions, and so on.
+By continuously testing such installation scripts, executable documentation allows one to detect problems and fix obsolete instructions as early as possible, avoiding headaches and frustration, for new end users and experienced developers alike.
+
++Technically, executable documentation can be created by using the Sphinx directive `literalinclude <https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-literalinclude>`_, which may include whole scripts or parts of them.
++For example, the following directive includes a script fragment detailing a step in compiling the Tezos sources::
+
+  .. literalinclude:: compile-sources.sh
+    :language: shell
+    :start-after: [install packages]
+    :end-before: [test executable]
+
+Whenever appropriate, in addition to including the script (fragment) in the documentation as above, make sure it is regularly tested, manually and/or within a CI job.
 
 Writing protocol documentation
 ------------------------------
diff --git a/docs/alpha/voting.rst b/docs/alpha/voting.rst
index 7bb6ff25b53a0cdd7b016ad4efdc1ffed8247e9c..ce14b4cde181f909bfb7427cc4e8ab6e446c259e 100644
--- a/docs/alpha/voting.rst
+++ b/docs/alpha/voting.rst
@@ -70,7 +70,7 @@ the current participation with the following coefficients::
   newQ = oldQ * 8/10 + participation * 2/10
 
 More details can be found in the file
-``src/proto_alpha/lib_protocol/amendment.ml``.
+:src:`src/proto_alpha/lib_protocol/amendment.ml`.
 
 Operations
 ----------
@@ -95,11 +95,11 @@ maximum number of proposals for that delegate.
 However duplicates from the same delegate are not tallied at the end
 of the proposal period.
 
-For example, a delegate submits a proposals operation for protocol A
+For example, a delegate submits a ``proposals`` operation for protocols A
 and B early in the proposal period, later a new protocol C is revealed
-and the delegate submits another proposals operation for protocol B
+and the delegate submits another ``proposals`` operation for protocols B
 and C.
-The list of submissions that will be tallied is [A,B,C] and the
+The list of submissions that will be tallied is [A,B,C].
 
 A ballot operation can only be submitted during one of the voting
 periods, and only once per period.
@@ -119,7 +119,7 @@ The pass vote allows a delegate to not influence a vote but still
 allowing it to reach quorum.
 
 More details can be found, as for all operations, in
-``src/proto_alpha/lib_protocol/operation_repr.ml``.
+:src:`src/proto_alpha/lib_protocol/operation_repr.ml`.
 The binary format is described by ``tezos-client describe unsigned
 operation``.
 
diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst
index 7279f5d356e6564a5454d39eb9702998b75a0e55..949f10d20365eabd7c1e1c4c376db2fe18f6a1e7 100644
--- a/docs/developer/contributing.rst
+++ b/docs/developer/contributing.rst
@@ -14,7 +14,7 @@ Reporting issues
 ~~~~~~~~~~~~~~~~
 
 The simplest way to contribute to Tezos is to report issues that you may
-find with the software on `gitlab <https://gitlab.com/tezos/tezos/-/issues>`__.
+find with the software on `GitLab <https://gitlab.com/tezos/tezos/-/issues>`__.
 If you are unsure about an issue
 consult the :ref:`technical support sources <support>`
 first and always make sure
@@ -25,11 +25,14 @@ Stretch*), the network you are connected to (e.g. *Carthagenet*), the
 binary or component (e.g. *tezos-node crashes* or *rpc X returns Y
 while Z was expected*).
 
-
 Going further
 ~~~~~~~~~~~~~
 
-To directly contribute to the codebase, expertise in a few areas is necessary.
++You may also want to fix some typos and minor errors or incoherencies in the *documentation*, which is situated in the ``docs/`` subfolder of the code repository.
+This kind of small contribution can be done without creating a merge request, by directly pushing commits to the ``typo-train`` branch, which is regularly merged into the master branch, e.g., every one or two weeks.
+Of course, all these commits will be reviewed before being integrated.
+
+To directly contribute to the *codebase*, expertise in a few areas is necessary.
 
 First, make sure that you are proficient enough in OCaml. The community
 website https://ocaml.org gives a few useful pointers for that. In
@@ -52,7 +55,7 @@ While you familiarize yourself with the basics as suggested above, you
 can have a look at the :ref:`software architecture
 <software_architecture>` of Tezos. It will
 give you the main components and their interactions, and links to the
-documentations for the various parts.
+documentation for the various parts.
 
 Now, that you're ready to delve into the code, it is time to know how
 contributions to the code are submitted, reviewed, and finally accepted into the master branch.
@@ -236,7 +239,7 @@ Therefore, when creating your MR, observe the following rules:
 
   - Isolate complicated parts of your patch in their own commits.
   - Put simple, non-controversial commits first. For instance: commits
-    which fix typos, improve documentation, or are simple enough that
+    that fix typos, improve documentation, or are simple enough that
     we may want to merge them even without the rest of the merge
     request.
     Even better put them in a separate MR which can be merged easily.
@@ -446,7 +449,7 @@ pitfalls a code reviewer should avoid.
   what else would have to change? How could we make this more maintainable?
 
 - Discuss in person for more detailed points: Online comments are useful for
-  focused technical questions. In many occasions it is more productive to
+  focused technical questions. On many occasions it is more productive to
   discuss it in person rather than in the comments. Similarly, if discussion
   about a point goes back and forth, It will be often more productive to pick
   it up in person and finish out the discussion.
@@ -482,7 +485,7 @@ pitfalls a code reviewer should avoid.
 
 - Consider the person you are reviewing: Each developer is a person. If you
   know the person, consider their personality and experience while reviewing their
-  code. Sometime it is possible with somebody to be more direct and terse, while
+  code. Sometimes it is possible with somebody to be more direct and terse, while
   other people require a more thorough explanation.
 
 - Avoid confrontational and authoritative language: The way we communicate has
@@ -492,9 +495,9 @@ pitfalls a code reviewer should avoid.
   a problem in the code : "This operation is wrong. Please fix it." and
   "Doing this operation might result in an error, can you please
   review it?". The first one implies you made an error (confrontational), and
-  you should fix it (authority). The second suggest to review the code because
+  you should fix it (authority). The second suggests to review the code because
   there might be a mistake. Despite the message being the same, the recipient might
-  have a different reactions to it and impact on the quality of this work. This
+  have a different reaction to it and impact on the quality of this work. This
   general remark is valid for any comment.
 
 .. _merge_bot:
diff --git a/docs/developer/guidelines.rst b/docs/developer/guidelines.rst
index 34cb55598fa0ab6b9da46e17f30d1b3fbdf9ae8a..b1c38117a89a271b15306e878e92176d3c184249 100644
--- a/docs/developer/guidelines.rst
+++ b/docs/developer/guidelines.rst
@@ -66,11 +66,12 @@ FIXME comments
 During the :ref:`code review process <code_review>`, follow-up issues may be created, for instance to improve or generalize some piece of code.
 When the place of the future fix is known in advance (e.g. a given function), you should mark it with a FIXME comment of the form::
 
-    (* FIXME (<issue>): <one-line explanation>
+    (* FIXME: <reference to issue>
+       <one-line explanation>
        <Add long explanation if the issue description is not the right place.>
     *)
 
-Note that the reference to an existing issue is mandatory, and might be checked automatically by the :ref:`Merge-Request Bot <merge_bot>`.
+Note that the reference to an existing issue on the first line is mandatory, to facilitate searches of FIXMEs corresponding to given issues, and might be checked automatically by the :ref:`Merge-Request Bot <merge_bot>`.
 
 Documenting interfaces and implementations
 ------------------------------------------
diff --git a/docs/developer/snoop_example.rst b/docs/developer/snoop_example.rst
index 2bc819552457b82baa5521c565a13917ef6603ca..b6cfee7c9299919943d232fb566f7b456320f8d7 100644
--- a/docs/developer/snoop_example.rst
+++ b/docs/developer/snoop_example.rst
@@ -190,10 +190,10 @@ The tool returns the following on standard output:
 
 This commands measures `100000` times the latency of the timer, that is
 the minimum time between two timing measurements. This yields an empirical distribution
-on timings. The tools takes the 50th percentile (ie the median) of the empirical distribution
+on timings. The tool takes the 50th percentile (ie the median) of the empirical distribution
 and returns the result: 25ns latency. This is reasonable.
 Since there's only one benchmark (with many samples), the standard deviation is by definition
-zero. One could also run many benchmarks with less samples per benchmark:
+zero. One could also run many benchmarks with fewer samples per benchmark:
 
 .. code-block:: shell
 
@@ -231,7 +231,7 @@ Step 3: benchmarking
 
 If the results obtained in the previous section are reasonable,
 we can proceed to the generation of raw timing data. We want
-to invoke the ``Blake2b_example`` benchmark and save the resulting data to `./blake2b.workload`.
+to invoke the ``Blake2b_example`` benchmark and save the resulting data to ``./blake2b.workload``.
 We want `500` distinct random inputs, and for each stack we will perform
 the timing measurement `3000` times. The ``--determinizer`` option specifies
 how the empirical timing distribution corresponding to the per-stack `3000` samples
@@ -313,16 +313,16 @@ At the time of writing, the tool offloads the regression problem to the scikit-l
 
 The command performed the following tasks:
 
-- load the workload data from `blake2b.workload`;
+- load the workload data from ``blake2b.workload``;
 - construct a linear regression problem using the chosen model: here,
   the ``Blake2b_example`` benchmark only provides the ``blake2b`` model;
 - solve this problem using the specified ``lasso`` algorithm, with the
   constraint that the inferred coefficients must be positive;
-- dump the result of inference to a csv file named `blake2b.csv`;
-- save a structured solution (useful for code generation) to `blake2b.sol`;
+- dump the result of inference to a csv file named ``blake2b.csv``;
+- save a structured solution (useful for code generation) to ``blake2b.sol``;
 - plot the result of inference.
 
-Let's first have a look at the contents of the CSV solution `blake2b.csv`.
+Let's first have a look at the contents of the CSV solution ``blake2b.csv``.
 
 .. csv-table:: Inference results
    :header: "blake2b_const", "blake2b_ns_p_byte"
@@ -364,7 +364,7 @@ but the principle is similar.
 By default, the tool produces integer code by casting floating point constant to integers.
 The tool produces the following code on ``stdout``:
 
-:: code-block:: ocaml
+.. code-block:: ocaml
 
    let model_blake2b_codegen size =
        (int_of_float 144.753899773) + (int_of_float 1.17988921492) * size
@@ -389,7 +389,7 @@ Calling the tool:
 
 We get:
 
-:: code-block:: ocaml
+.. code-block:: ocaml
 
    let model_blake2b_codegen size =
        let v0 = size in
diff --git a/docs/index.rst b/docs/index.rst
index 4bd5f129e9bfe736b3b1964af36f2dc4284ad8f9..32d5960a42b276a422c6876fb51c0ed2ad260f01 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -102,14 +102,14 @@ in the :ref:`introduction <howtoget>`.
    :caption: User documentation:
 
    user/key-management
+   user/node-configuration
+   user/snapshots
+   user/history_modes
+   user/multinetwork
    user/sandbox
    user/mockup
    user/proxy
    user/light
-   user/history_modes
-   user/snapshots
-   user/node-configuration
-   user/multinetwork
    user/various
 
 .. toctree::
diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst
index e61dde017483af5920bf23d86fffaf0e5a93b194..849f3c7c5046292abe261b671032be171dd8a0c4 100644
--- a/docs/introduction/howtoget.rst
+++ b/docs/introduction/howtoget.rst
@@ -160,7 +160,6 @@ executed by using ``./edo2net.sh client``, passing the needed arguments. Similar
 can be executed using ``./edo2net.sh admin-client``.
 
 
-.. _build_from_sources:
 .. _building_with_opam:
 
 Building from sources via OPAM
@@ -284,6 +283,7 @@ Identified situations where it will be more tricky are:
   The solution will be defined when delivering the first release with Rust
   dependencies.
 
+.. _build_from_sources:
 .. _compiling_with_make:
 
 Setting up the development environment from scratch
diff --git a/docs/introduction/support.rst b/docs/introduction/support.rst
index cd8a369eed71daf98e3fb1527f411b6eb0d6d8e3..6e98cd0f9032cd1d67a3bb1dba269baa5de78712 100644
--- a/docs/introduction/support.rst
+++ b/docs/introduction/support.rst
@@ -20,3 +20,6 @@ to find answers.
 - There is a *#tezos* IRC channel on *freenode* that is reserved for
   technical discussions and is always very active.
 - There is a matrix channel *Tezos* that you can join `here <https://riot.im/app/#/room/#tezos:matrix.org>`_.
+
+For anything baking related, there is a dedicated Slack channel, https://tezos-baking.slack.com.
+If you don't have access to the Tezos Baking Slack, send an e-mail to `joinslack@tezos-kiln.org <mailto:joinslack@tezos-kiln.org>`_ to join this channel.
diff --git a/docs/releases/version-9.rst b/docs/releases/version-9.rst
index cc2f40a811f972f4dccbbe34a033414fce52947d..9f7351e050c8fb7b2e6e4646c48f67c0105c55a1 100644
--- a/docs/releases/version-9.rst
+++ b/docs/releases/version-9.rst
@@ -32,7 +32,7 @@ Known Issues
 ------------
 
 Regular but infrequent (a few times a day) spikes of RAM usage have
-been noticed. If you run a node on hardware with less than 8Go of RAM
+been noticed. If you run a node on hardware with less than 8 GB of RAM
 you should activate some swap to handle those spikes. Of course, swap
 may have a price in terms of performance. To not risk any slowdown at
 all, especially when baking on Mainnet, the safest option is to have
diff --git a/docs/user/history_modes.rst b/docs/user/history_modes.rst
index 5a4333df74b34a63f3780bd9f9087b10792d2c57..1790054bbeef38c60399e75bfcadd5d0e49622ec 100644
--- a/docs/user/history_modes.rst
+++ b/docs/user/history_modes.rst
@@ -1,7 +1,7 @@
 .. _history-modes:
 
 History modes
--------------
+=============
 
 History modes allow a node to require less disk storage. Indeed,
 depending on the chosen history mode, some parts of the complete chain
diff --git a/src/proto_alpha/lib_protocol/storage_description.ml b/src/proto_alpha/lib_protocol/storage_description.ml
index f41bb1c5710c967e2e051d582f903333e6ae3b47..448bd16c1461618027d046729a97a177dad2d89f 100644
--- a/src/proto_alpha/lib_protocol/storage_description.ml
+++ b/src/proto_alpha/lib_protocol/storage_description.ml
@@ -31,7 +31,10 @@ type 'key t = 'key desc_with_path
     [rev_path] which is the reverse path up to the position, and [dir] the
     position's [description]. [rev_path] is only useful in case of an error to
     print a descriptive message. [List.rev rev_path] is a storage's path that
-    contains no conflict and allow the registration of a [dir]'s storage. *)
+    contains no conflict and allows the registration of a [dir]'s storage.
+    NB: [rev_path] indicates the position in the tree, so once the node is
+    added, it won't change; whereas [dir] is mutable because when more subtrees
+    are added this may require updating it. *)
 and 'key desc_with_path = {
   rev_path : string list;
   mutable dir : 'key description;