diff --git a/docs/contributing/code-review.rst b/docs/contributing/code-review.rst
index f64964e..e299203 100644
--- a/docs/contributing/code-review.rst
+++ b/docs/contributing/code-review.rst
@@ -1,51 +1,51 @@
 .. _code-review:
 
 Code Review
 ===========
 
-This page documents code review practices used for [[Software Heritage]] development.
+This page documents code review practices used for Software Heritage development.
 
 Guidelines
 ----------
 
 Please adhere to the following guidelines to perform and obtain code reviews
 (CRs) in the context of Software Heritage development:
 
 1. **CRs are strongly recommended** for any non-trivial code change,
    but not mandatory (nor enforced at the VCS level).
 2. The CR `workflow <phabricator-arcanist>`_ is implemented using
    Phabricator/Differential.
 3. Explicitly **suggest reviewer(s)** when submitting new CR requests:
    either the most knowledgeable person(s) for the target code or the general
    `reviewers <https://forge.softwareheritage.org/project/view/50/>`_
    (which is the `default <https://forge.softwareheritage.org/H18>`_).
 4. **Review anything you want**: no matter the suggested reviewer(s),
    feel free to review any outstanding CR.
 5. **One LGTM is enough**: feel free to approve any outstanding CR.
 6. **Review every day**: CRs should be timely as fellow developers
    will wait for them.
    To make CRs sustainable each developer should strive to dedicate
    a fixed minimum amount of CR time every (work) day.
 
 For more detailed suggestions (and much more) on the motivational
 and practical aspects of code reviews see Good reads below.
 
 Good reads
 ----------
 
 Good reads on various angles of code review:
 
 * `Best practices <https://medium.com/palantir/code-review-best-practices-19e02780015f>`_ (Palantir) ← comprehensive and recommended read, especially if you're short on time
 * `Best practices <https://github.com/thoughtbot/guides/tree/master/code-review>`_ (Thoughtbot)
 * `Best practices <https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/>`_ (Smart Bear)
 * `Review checklist <https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines>`_ (Code Project)
 * `Motivation: code quality <https://blog.codinghorror.com/code-reviews-just-do-it/>`_ (Coding Horror)
 * `Motivation: team culture <https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs/>`_ (Google & FullStory)
 * `Motivation: humanizing peer reviews <http://www.processimpact.com/articles/humanizing_reviews.pdf>`_ (Wiegers)
 * `Motivation: sharing knowledge <https://www.atlassian.com/agile/software-development/code-reviews>`_ (Atlassian)
 
 See also
 --------
 
 * :ref:`phabricator-arcanist`
 * :ref:`coding-guidelines`
diff --git a/docs/contributing/python-style-guide.rst b/docs/contributing/python-style-guide.rst
index 7c3180d..5ec963e 100644
--- a/docs/contributing/python-style-guide.rst
+++ b/docs/contributing/python-style-guide.rst
@@ -1,67 +1,67 @@
 .. _python-style-guide:
 
 Python style guide
 ==================
 
-Coding style and best practices for writing Python code for [[Software Heritage]].
+Coding style and best practices for writing Python code for Software Heritage.
 
 General rules
 -------------
 
 * As a general rule, follow the
   `Google Python Style Guide <http://google.github.io/styleguide/pyguide.html>`_.
 * Target **Python 3**. Do not care about backward compatibility with Python 2.
 
 Black
 +++++
 
 As of April 2020, we use `Black <https://black.readthedocs.io/>`_
 as automated code formatter for all Software Heritage Python code.
 CI, tox, and other linting tools are configured to fail
 if code is not formatted as black would.
 
 Note that, as part of this, *maximum line length is 88 characters*,
 rather than the default of 79.
 
 Specific rules
 --------------
 
 As supplement/overrides to the above general rules,
 follow the additional recommendations below.
 
 Lint
 ++++
 
 * Make sure your code is `flake8 <https://flake8.readthedocs.org/>`_
   and `Black <https://black.readthedocs.io/>`_ clean.
 
 Tests
 +++++
 
 * use ``pytest`` as test runner
 * put ``tests/`` dir down deep in the module hierarchy, near to the code being tested
 * naming conventions:
 ** ``tests/test_mymodule.py``
 ** ``class TestMyEntity(unittest.TestCase)``
 ** ``def behavior(self):``
 *** do *not* prepend ``test_`` to all test methods;
     use nose's ``@istest`` decorator instead
 
 Classes
 +++++++
 
 * Since we target Python 3, there is no need to
   `inherit from 'object' explicitly <http://google.github.io/styleguide/pyguide.html?showone=Classes#Classes>`_
 
 Docstrings
 ---------
 
 * docstrings should produce a nice API documentation when run through
   `Sphinx <http://www.sphinx-doc.org/en/stable/`_, in particular:
 * docstrings should be written in
   `reStructuredText <http://www.sphinx-doc.org/en/stable/rest.html>`_
 * docstrings should use the
   `Napoleon style <http://www.sphinx-doc.org/en/stable/ext/napoleon.html>`_
   (Google variant) to document arguments, return values, etc.
 ** see also: a `comprehensive style example <http://www.sphinx-doc.org/en/stable/ext/example_google.html#example-google>`_
 ** see also: :ref:`sphinx-gotchas`