tweaks documentation

documentation/sphinx_static/development.rst

@@ -33,7 +33,7 @@ Once I get feedback from someone who actually knows how to handle bigger
 projects, these may change.
 
 1. New features are worked on in branches forked from ``develop``, with
-   the branch name of the form ``feature/bla``.
+   the branch name of the form ``feature/new``.
    Feature branches are merged back into ``develop`` only after all tests
    pass.
 2. Whenever the ``develop`` branch is merged into ``master``, the last
@@ -51,6 +51,7 @@ projects, these may change.
 4. Whenever a bug is discovered in version X.Y.Z, a bugfix branch is
    forked from ``vX.Y``, and then rule 3 is adapted accordingly.
 
+Please also read "code review" section below.
 
 ------------
 Code testing
@@ -59,3 +60,29 @@ Code testing
 We use CTest for testing `TurTLE`, and the ``.gitlab-ci.yml`` script
 calls CTest.
 
+-----------
+Code review
+-----------
+
+For each merge request a review should be conducted.
+Ideally, a person other than the initiator of the merge request should
+review the code.
+
+Code reviews can be more or less thorough, depending on how many
+separate "review steps" are gone through.
+
+Possible steps, not an exhaustive list:
+
+0. No regressions.
+   I.e. merge requests should not introduce mistakes into the code.
+   To the extent that the CI coverage is adequate, "the pipeline passes"
+   is a reasonable proxy for "no regressions".
+
+1. New functionality is tested.
+   Ideally a new test is added aimed at newly implemented functionality.
+   In the case of bugfixes, a test can simply consist of triggering the
+   bug.
+   In this sense, the reviewer is encouraged to define a clear pass/fail
+   test that the updated code should pass.
+   Depending on concrete details, it may be better if the reviewer
+   writes the test that needs to pass.