diff --git a/docs/rolereference.rst b/docs/rolereference.rst
index 7ce18ec09981b14fff4ddc8323099ab8c8424b1e..29b8111438bdfe95010274b0a0ef6b49f8f9c9e8 100644
--- a/docs/rolereference.rst
+++ b/docs/rolereference.rst
@@ -289,19 +289,23 @@ The role implements the following:
   upgrades on daily basis. Mails are delivered to local ``root`` account, and
   can be redirected elsewhere via aliases. If using ``mail_forwarder`` or
   ``mail_server`` roles on the same server, aliases can be set-up through them.
-* Sets-up system for performing checks on pip requirements files. Roles that
-  want their requirements files checked should create a sub-directory inside of
-  ``/etc/pip_check_requirements_upgrades``, and place ``.txt`` and ``.in`` files
-  inside (with same base name). The ``.txt`` files should be standard
-  requirements files with fixed versions (the ones installed by the role). The
-  ``.in`` files should contain only the top-level packages (no
-  dependencies). Avoid hard-coding versions in the ``.in`` file unless really
-  needed. For packages where you want to stick to stable/LTS version branch, you
-  should be able to use ``~=`` operator (for example ``django~=1.8.0``. Checks
-  are implemented via `pip-tools <https://github.com/jazzband/pip-tools>`_ and a
-  custom script that outputs diffs if upgrades are available. Script is run via
-  cronjob on daily basis, and any output will be delivered to local ``root``
-  user.
+* Sets-up system for performing checks on pip requirements
+  files. Roles that want their requirements files checked should
+  create a sub-directory inside of
+  ``/etc/pip_check_requirements_upgrades`` (for Python 2
+  applications), or ``/etc/pip_check_requirements_upgrades-py3`` (for
+  Python 3 applications), and place ``.txt`` and ``.in`` files inside
+  (with same base name). The ``.txt`` files should be standard
+  requirements files with fixed versions (the ones installed by the
+  role). The ``.in`` files should contain only the top-level packages
+  (no dependencies). Avoid hard-coding versions in the ``.in`` file
+  unless really needed. For packages where you want to stick to
+  stable/LTS version branch, you should be able to use ``~=`` operator
+  (for example ``django~=1.8.0``. Checks are implemented via
+  `pip-tools <https://github.com/jazzband/pip-tools>`_ and a custom
+  script that outputs diffs if upgrades are available. Script is run
+  via cronjob on daily basis, and any output will be delivered to
+  local ``root`` user.
 * Optionally configures time synchronisation using NTP (if
   ``ntp_servers`` parameter is set).