Fix docs

Author: smoia

docs/contributorfile.rst

@@ -198,7 +198,7 @@ Pull Requests
 -------------
 To improve understanding pull requests "at a glance" and use the power of ``auto``, we use the labels listed above. Multiple labels can be assigned to a PR - in fact, all those that you think are relevant.
 We strongly advise to keep the changes you're introducing with your PR limited to your original goal. Adding to the scope of your PR little style corrections or code refactoring here and there in the code that you're already modifying is a great help, but when they become too much (and they are not relevant to your PR) they risk complicating the nature of the PR and the reviewing process. It is much better to open another PR with the objective of doing such corrections!
-Moreover, if you're tempted to assign more than one label that would trigger a release (e.g. `bug` and `minormod`, or `bug` and `majormod`, etc. etc.), you might want to split your PR instead.
+Moreover, if you're tempted to assign more than one label that would trigger a release (e.g. ``bug`` and ``minormod``, or ``bug`` and ``majormod``, etc. etc.), you might want to split your PR instead.
 When opening a pull request, assign it at least one label.
 
 We encourage you to open a PR as soon as possible - even before you finish working on them. This is useful especially to you - so that you can receive comments and suggestions early on, rather than having to process a lot of comments in the final review step!
@@ -207,8 +207,8 @@ However, if it’s an incomplete PR, please open a **Draft PR**. That helps us p
 Reviewing PRs is a time consuming task and it can be stressful for both the reviewer and the author. Avoiding wasting time and the need of little fixes - such as fixing grammar mistakes and typos, styling code, or adopting conventions - is a good start for a successful (and quick) review. Before graduating a Draft PR to a PR ready for review, please check that:
 
 - You did all you wanted to include in your PR. If at a later stage you realise something is missing and it's not a minor thing, you will need to open a new PR.
-- If your contribution contains code or tests, you ran and passed all of the tests locally with `pytest`.
-- If you're writing documentation, you built it locally with `sphinx` and the format is what you intended.
+- If your contribution contains code or tests, you ran and passed all of the tests locally with ``pytest``.
+- If you're writing documentation, you built it locally with ``sphinx`` and the format is what you intended.
 - Your code is harmonious with the rest of the code - no repetitions of any sort!
 - Your code respects the `adopted Style <#styling>`_, especially:
     - Your code is lintered adequately and respects the `PEP8 <https://www.python.org/dev/peps/pep-0008/>`_ convention.
@@ -222,7 +222,7 @@ To be merged, PRs have to:
 
 1. Pass all the CircleCI tests, and possibly all the codecov checks.
 2. Have the necessary amount of approving reviews, even if you’re a long time contributor. You can ask one (or more) contributor to do that review, if you think they align more with the content of your PR. You need **one** review for documentation, tests, and small changes, and **two** reviews for bugs, refactoring and enhancements.
-3. Have at least a release-related label (or a `Skip release` label).
+3. Have at least a release-related label (or a ``Skip release`` label).
 4. Have a short title that clearly explains in one sentence the aim of the PR.
 5. Contain at least a unit test for your contribution, if the PR contains code (it would be better if it contains an integration or function test and all the breaking tests necessary). If you’re not confident about writing tests, it is possible to refer to an issue that asks for the test to be written, or another (Draft) PR that contains the tests required.
 

docs/heuristic.rst

@@ -31,7 +31,7 @@ It's important **not to modify this part of the file**. Instead, you can copy an
 This file looks like a python function, initialised by a mandatory parameter, ``physinfo``.
 | ``physinfo`` is the information used to label your file. **At the moment, it corresponds to the name of the input file itself**. This is what you need to build your heuristic.
 
-The function initialises ``info``, a `python dictionary <https://www.w3schools.com/python/python_dictionaries.asp>`_ that contains the BIDS keys, such as `sub` and `ses`, as well as all the possible keys you can add to your heuristics. This is what you will work with in creating your heuristic.
+The function initialises ``info``, a ``python dictionary <https://www.w3schools.com/python/python_dictionaries.asp>``_ that contains the BIDS keys, such as ``sub`` and ``ses``, as well as all the possible keys you can add to your heuristics. This is what you will work with in creating your heuristic.
 
 The scripts also imports ``fnmatch``, a nice python module that lets you use bash-like wildcards.