diff --git a/docs/Dev.rst b/docs/Dev.rst
index dbdd8aa..aa25b86 100755
--- a/docs/Dev.rst
+++ b/docs/Dev.rst
@@ -1,332 +1,338 @@
 =============================
 Developing the RoSA Framework
 =============================
 
 .. contents::
    :local:
 
 This document provides information that might be useful for contributing to
 RoSA. Please also consult :doc:`Build`.
 
 .. _Dev_Source_Directory:
 
 The Source Directory
 ====================
 
 The source directory consists of the following subdirectories:
 
 `cmake`
   Contains files used for configuring the `CMake Project`_.
 
 `docs`
   Contains `Documentation`_-related files.
 
 `examples`
   Contains `Examples`_ on using the public API.
 
 `include/rosa`
   Contains the RoSA public API -- that is the interface of RoSA `Libraries`_.
   The directory `include` is to be used as include directory and RoSA header
   files are to be included in C++ sources as `"rosa/"`.
 
 `lib`
   Contains the implementation of the RoSA public API -- that is the
   implementation of RoSA `Libraries`_.
 
 `tools`
   Contains `Tools`_ based on RoSA features.
 
 
 Software Sources
 ================
 
 The section describes the `Logical Structure`_ of the software sources and what
 `Coding Standards`_ are supposed to be followed for the implementation.
 
 Logical Structure
 -----------------
 
 Various features provided by RoSA are sorted into different `Libraries`_.
 `Examples`_ and `Tools`_ using those `Libraries`_ are separated from the
 implementation of the RoSA features into different directories.
 
 Libraries
 ~~~~~~~~~
 
 The framework consists of separate libraries providing different features. The
 public interfaces for RoSA libraries are defined in `include/rosa`, while
 corresponding implementation is in `lib`. Each library has its own subdirectory
 in the mentioned directories.
 
 RoSA provides the following libraries:
 
 `config`
   Provides information on the configuration used to build the framework, e.g.,
   version number, log level, assertions, and debugging.
 
 `support`
   Provides general features -- template metaprograms dealing with types, for
   instance -- for implementing other libraries.
 
 `core`
   Provides the basic RoSA features, like systems managing agents passing
   messages.
 
 `agent`
   Provides features to be used for implementing agents.
 
 
 .. _Library_Dependencies:
 
 Dependencies
 ''''''''''''
 
 The following table summarizes dependencies among libraries.
 
 A marking in a row denotes that the library in the beginning of the row depends
 on the library in the head of the given column.
 
 +---------+--------+---------+------+-------+
 |         | config | support | core | agent |
 +=========+========+=========+======+=======+
 | config  |        |         |      |       |
 +---------+--------+---------+------+-------+
 | support |        |         |      |       |
 +---------+--------+---------+------+-------+
 | core    |        |    ×    |      |       |
 +---------+--------+---------+------+-------+
 | agent   |        |         |      |       |
 +---------+--------+---------+------+-------+
 
 Examples
 ~~~~~~~~
 
 Some simple samples are provided in `examples` to demonstrate how to to use
 different parts of the RoSA API.
 
 Tools
 ~~~~~
 
 Tools, programs based on the RoSA libraries, are implemented in `tools`.
 
 .. _Coding_Standards:
 
 Coding Standards
 ----------------
 
 RoSA is implemented in standard *C++14* code. All the software sources are to
 be written in accordance to the `LLVM Coding Standards`_.
 
 Documentation Comments
 ~~~~~~~~~~~~~~~~~~~~~~
 
 It is important to remember to document source code using `doxygen comments`_
 as `API Documentation`_ is generated directly from sources.
 
-Note that the syntax of documentation comments is checked during compilation,
+Note that the syntax of documentation comments is checked during compilation --
 at least when using a GCC-compatible compiler.
 
-If declarations belonging to a namespace spread to more than one source file,
-document the namespace in `include/rosa/config/namespaces.h`. Otherwise,
+Whenever you work on a source file, make sure your name is in the author-list
+defined in the header comment of the file. Each author should be defined with a
+separate `\\author` command so that recent authors come first. Authors not
+participating in further development of a file anymore may be marked with the
+period of their contribution.
+
+If declarations belonging to a namespace are spread to more than one source
+files, document the namespace in `include/rosa/config/namespaces.h`. Otherwise,
 document the namespace in the only file in which entities of the namespace are
 declared.
 
 Header Files
 ~~~~~~~~~~~~
 
 Follow the recommendations on public and private header files and the usage of
 `#include` from the `LLVM Coding Standards`_.
 
 Use `.h` and `.hpp` extensions to indicate the content of the header file:
 
 * header files containing any *definition* -- template or inline definition --
   or including another header file with `.hpp` extension have `.hpp` extension;
 * header files containing only *declarations* and including only header files
   with `.h` extension have `.h` extension.
 
 Checking and Enforcing the Coding Standards
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The tools `clang-tidy <https://clang.llvm.org/extra/clang-tidy/>`_ and
 `clang-format <https://clang.llvm.org/docs/ClangFormat.html>`_ can be used to
 check and enforce the coding standards. The two tools are integrated into the
 CMake project, refer to CMake variables
 :ref:`ROSA_ENABLE_CLANG_TIDY <CMake_clang_tidy>` and
 :ref:`ROSA_INCLUDE_CLANG_FORMAT <CMake_clang_format>`.
 
 Note that there may be situations when `clang-tidy` checks result in false
 positives -- for example, for some cases of the order of `#include` directives.
 One can order `clang-tidy` to suppress warnings for a line of code by marking
 that line with::
 
   // NOLINT
 
 It may be preferred to diverge from the standard formatting -- for example for
 the sake of readability of static definition of arrays following some
 structure. One can disable `clang-format` for some lines of code by designating
 a range with two special comments as::
 
   // clang-format off
 
   ... clang-format is disabled here ...
 
   // clang-format on
 
 Documentation
 =============
 
 The RoSA Framework is delivered with two kinds of documentation: `General
 Documentation`_ and `API Documentation`_, generation of both of which is
 integrated into the CMake project.
 
 References between the two documentations are relative addresses corresponding
 to the directory structure of the
 :ref:`generated documentation <Build_Result_Documentation>`.
 
 General Documentation
 ---------------------
 
 General documentation is written as
 `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ compiled with
 `Sphinx <http://www.sphinx-doc.org/>`_. For build integration, refer to the
 CMake variable :ref:`ROSA_ENABLE_SPHINX <CMake_sphinx>`.
 
 Documentation files are located in `docs` with extension `.rst`. The main
 page of the documentation is `docs/index.rst`. Configuration for building the
 documentation is `docs/conf.py`.
 
 The directory `docs/CommandGuide` contains documentation for each separate
 tool. Those pages are included in the HTML documentation via
 `docs/CommandGuide/index.rst`. Moreover, man pages can be generated from those
 tool documentation pages.
 
 API Documentation
 -----------------
 
 API documentation is directly generated from sources with
 `Doxygen <http://doxygen.org>`_. For build integration, refer to the CMake
 variable :ref:`ROSA_ENABLE_DOXYGEN <CMake_doxygen>`.
 
 The main page used for the API documentation is `docs/doxygen-mainpage.dox`.
 Configuration for generating the API documentation is `docs/doxygen.cfg.in`.
 
 .. _CMake Project:
 
 Managing the CMake Project
 ==========================
 
 This section briefly summarizes when and how to modify CMake files during
 the development process. No general discussion on CMake features is provided
 here.
 
 When modifying `Documentation`_, no need to update the CMake files.
 
 Software
 --------
 
 One needs to modify the CMake files only if source files are to be added or
 removed from the project. Here follows some typical scenarios.
 
 Source Files
 ~~~~~~~~~~~~
 
 Each library and executable target has its own directory and its own definition
 as a file called `CMakeLists.txt` in that directory.
 
 When adding or removing a source file -- both headers and `.cpp` files -- to a
 library or executable, locate the corresponding `CMakeLists.txt` file. The file
 is typically in the same directory where the file to be added or removed is
 located. Except for header files of the public API, for which the corresponding
 CMake target is defined in a `lib` subdirectory corresponding to the library the
 header files belongs to.
 
 Update the source list in the argument of the `add_library` or `add_executable`
 command in the `CMakeLists.txt`, for libraries and executables, respectively.
 
 A library and executable may use features provided by another library. Such a
 dependency is to be defined in the `CMakeLists.txt` file of the dependent
 target by using the `ROSA_add_library_dependencies` command.
 
 CMake Libraries
 ~~~~~~~~~~~~~~~
 
 When adding or removing a library, add or remove the corresponding directories
 from `include` and `lib`, and also update `lib/CMakeLists.txt` by adding or
 removing a `add_subdirectory` command for the library.
 
 When defining a new library, the new subdirectory under `lib` needs to contain a
 `CMakeLists.txt`, which needs to contain at least an `add_library` command
 defining the name of the library and the source files belonging to it.
 
 CMake Executables
 ~~~~~~~~~~~~~~~~~
 
 When adding or removing an executable, add or remove the corresponding
 directory from `examples` or `tools`, and also update `CMakeLists.txt` in the
 containing directory as for libraries.
 
 When defining a new executable, the new subdirectory needs to contain a
 `CMakeLists.txt`, which needs to contain at least an `add_executable` command
 defining the name of the executable and the source files belonging to it.
 
 .. _Dev Managing Sources:
 
 Managing Sources
 ================
 
 Consider the followings before committing changes to the repository:
 
 * your code complies with the `Coding Standards`_ as much as possible;
 * your code is well documented;
 * your code is not bloated with unusued code and/or comments;
 * your changes do not break building and executing the framework:
 
   * test all of the supported platforms if possible,
   * look into the generated documentation if you have edited
     `General Documentation`_;
 
 * you do not pollute the repository with unused and generated files.
 
 When committing changes to the repository, provide a concise log message with
 your commit.
 
 Miscellaneous Concerns
 ======================
 
 Using YCM
 ---------
 
 If you happen to use `YCM <https://github.com/Valloric/YouCompleteMe>`_, just
 make a copy of the provided `ycm_extra_conf.py.template` file as
 `.ycm_extra_conf.py` in the RoSA source directory, and set the following two
 variables in it:
 
 `compilation_database_folder`
   the absolute path of your build directory
 
 `extra_system_include_dirs`
   any system include directory which might not be searched by `libclang` [1]_.
 
 You probably want compile with Clang if you use YCM, so run CMake with
 environment variables `CC=clang` and `CXX=clang++` set.
 
 Also note that header files in the `include` directory are compiled for YCM with
 the compiler flags of a corresponding source file in the `lib` directory, if
 any. Header files in other locations are supposed to have a corresponding source
 file in the same directory.
 
 Notes
 ~~~~~
 
 * If the project's include directory (`include/rosa`) would ever be changed,
   then the YCM configuration file needs to be adjusted accordingly.
 
 ----
 
 .. [1] See: https://github.com/Valloric/YouCompleteMe/issues/303; use the
        following command to figure out the used system directories:
 
          echo | clang -std=c++11 -v -E -x c++ -
 
 .. _`LLVM Coding Standards`: http://llvm.org/docs/CodingStandards.html
 .. _`doxygen comments`: http://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments
diff --git a/docs/Issues.rst b/docs/Issues.rst
index d4828fe..b2cf67f 100755
--- a/docs/Issues.rst
+++ b/docs/Issues.rst
@@ -1,31 +1,32 @@
 ==================================================================
 Known Issues with the Current Implementation of the RoSA Framework
 ==================================================================
 
 .. contents::
    :local:
 
 TODO
 ====
 
 * Project logo - `docs/_themes/rosa-theme/static/logo.png`
-* CAF license?
+* License?
 * Packaging with
   `CPack <https://cmake.org/cmake/help/latest/module/CPack.html>`_.
+* What about design documentation on the basics of RoSA?
 * What about testing the framework?
 
 Known Issues
 ============
 
 * CMake
 
   * VS2017 generates intermediate files for the `ZERO_CHECK` project out of the
     build directory, see `CMake issue #16458`_.
   * VS2017 with `v141_clang_c2` toolset requires
     :ref:`fix of the generated Visual Studio projects <CMake-VS2017-Clang-fix>`.
 
 * clang-format
 
   * `include/rosa/core/Message.hpp` breaks clang-format as of version 3.8.0.
 
 .. _CMake issue #16458: https://gitlab.kitware.com/cmake/cmake/issues/16458
diff --git a/docs/conf.py b/docs/conf.py
index cc3cf2d..9cc18d3 100755
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -1,253 +1,253 @@
 # -*- coding: utf-8 -*-
 #
 # RoSA documentation build configuration file.
 #
 # This file is execfile()d with the current directory set to its containing dir.
 #
 # Note that not all possible configuration values are present in this
 # autogenerated file.
 #
 # All configuration values have a default; values that are commented out
 # serve to show the default.
 
 import sys, os
 from datetime import date
 
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 #sys.path.insert(0, os.path.abspath('.'))
 
 # -- General configuration -----------------------------------------------------
 
 # If your documentation needs a minimal Sphinx version, state it here.
 #needs_sphinx = '1.0'
 
 # Add any Sphinx extension module names here, as strings. They can be extensions
 # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
 extensions = ['sphinx.ext.intersphinx', 'sphinx.ext.todo']
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
 
 # The suffix of source filenames.
 source_suffix = '.rst'
 
 # The encoding of source files.
 #source_encoding = 'utf-8-sig'
 
 # The master toctree document.
 master_doc = 'index'
 
 # General information about the project.
 project = u'RoSA'
-copyright = u'2016-%d, RoSA' % date.today().year
+copyright = u'%d, RoSA' % date.today().year
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
 # built documents.
 #
 # The short X.Y version.
 version = '0.1'
 # The full version, including alpha/beta/rc tags.
 release = '0.1.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
 #language = None
 
 # There are two options for replacing |today|: either, you set today to some
 # non-false value, then it is used:
 #today = ''
 # Else, today_fmt is used as the format for a strftime call.
 today_fmt = '%Y-%m-%d'
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 exclude_patterns = ['_build']
 
 # The reST default role (used for this markup: `text`) to use for all documents.
 #default_role = None
 
 # If true, '()' will be appended to :func: etc. cross-reference text.
 #add_function_parentheses = True
 
 # If true, the current module name will be prepended to all description
 # unit titles (such as .. function::).
 #add_module_names = True
 
 # If true, sectionauthor and moduleauthor directives will be shown in the
 # output. They are ignored by default.
 show_authors = True
 
 # The name of the Pygments (syntax highlighting) style to use.
 pygments_style = 'friendly'
 
 # A list of ignored prefixes for module index sorting.
 #modindex_common_prefix = []
 
 
 # -- Options for HTML output ---------------------------------------------------
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 html_theme = 'rosa-theme'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 html_theme_options = { "nosidebar": True }
 
 # Add any paths that contain custom themes here, relative to this directory.
 html_theme_path = ["_themes"]
 
 # The name for this set of Sphinx documents.  If None, it defaults to
 # "<project> v<release> documentation".
 #html_title = None
 
 # A shorter title for the navigation bar.  Default is the same as html_title.
 #html_short_title = None
 
 # The name of an image file (relative to this directory) to place at the top
 # of the sidebar.
 #html_logo = None
 
 # The name of an image file (within the static path) to use as favicon of the
 # docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
 # pixels large.
 #html_favicon = None
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
 html_static_path = ['_static']
 
 # If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
 # using the given strftime format.
 html_last_updated_fmt = '%Y-%m-%d'
 
 # If true, SmartyPants will be used to convert quotes and dashes to
 # typographically correct entities.
 #html_use_smartypants = True
 
 # Custom sidebar templates, maps document names to template names.
 html_sidebars = {'index': 'indexsidebar.html'}
 
 # Additional templates that should be rendered to pages, maps page names to
 # template names.
 #html_additional_pages = {}
 
 # If false, no module index is generated.
 #html_domain_indices = True
 
 # If false, no index is generated.
 #html_use_index = True
 
 # If true, the index is split into individual pages for each letter.
 #html_split_index = False
 
 # If true, links to the reST sources are added to the pages.
 html_show_sourcelink = True
 
 # If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
 #html_show_sphinx = True
 
 # If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
 #html_show_copyright = True
 
 # If true, an OpenSearch description file will be output, and all pages will
 # contain a <link> tag referring to it.  The value of this option must be the
 # base URL from which the finished HTML is served.
 #html_use_opensearch = ''
 
 # This is the file name suffix for HTML files (e.g. ".xhtml").
 #html_file_suffix = None
 
 # Output file base name for HTML help builder.
 htmlhelp_basename = 'RoSAdoc'
 
 
 # -- Options for LaTeX output --------------------------------------------------
 
 latex_elements = {
 # The paper size ('letterpaper' or 'a4paper').
 #'papersize': 'letterpaper',
 
 # The font size ('10pt', '11pt' or '12pt').
 #'pointsize': '10pt',
 
 # Additional stuff for the LaTeX preamble.
 #'preamble': '',
 }
 
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title, author, documentclass [howto/manual]).
 latex_documents = [
   ('index', 'RoSA.tex', u'RoSA Documentation',
    u'RoSA', 'manual'),
 ]
 
 # The name of an image file (relative to this directory) to place at the top of
 # the title page.
 #latex_logo = None
 
 # For "manual" documents, if this is true, then toplevel headings are parts,
 # not chapters.
 #latex_use_parts = False
 
 # If true, show page references after internal links.
 #latex_show_pagerefs = False
 
 # If true, show URL addresses after external links.
 #latex_show_urls = False
 
 # Documents to append as an appendix to all manuals.
 #latex_appendices = []
 
 # If false, no module index is generated.
 #latex_domain_indices = True
 
 
 # -- Options for manual page output --------------------------------------------
 
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = []
 
 # Automatically derive the list of man pages from the contents of the command
 # guide subdirectory.
 basedir = os.path.dirname(__file__)
 man_page_authors = ""
 command_guide_subpath = 'CommandGuide'
 command_guide_path = os.path.join(basedir, command_guide_subpath)
 for name in os.listdir(command_guide_path):
     # Ignore non-ReST files and the index page.
     if not name.endswith('.rst') or name in ('index.rst',):
         continue
 
     # Otherwise, automatically extract the description.
     file_subpath = os.path.join(command_guide_subpath, name)
     with open(os.path.join(command_guide_path, name)) as f:
         title = f.readline().rstrip('\n')
         header = f.readline().rstrip('\n')
 
         if len(header) != len(title):
             print >>sys.stderr, (
                 "error: invalid header in %r (does not match title)" % (
                     file_subpath,))
         if ' - ' not in title:
             print >>sys.stderr, (
                 ("error: invalid title in %r "
                  "(expected '<name> - <description>')") % (
                     file_subpath,))
 
         # Split the name out of the title.
         name,description = title.split(' - ', 1)
         man_pages.append((file_subpath.replace('.rst',''), name,
                           description, man_page_authors, 1))
 
 # If true, show URL addresses after external links.
 #man_show_urls = False
 
 # FIXME: Define intersphinx configuration.
 intersphinx_mapping = {}
diff --git a/docs/index.rst b/docs/index.rst
index 2e0d172..cc82f79 100755
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -1,70 +1,72 @@
 ==================
 The RoSA Framework
 ==================
 
 .. contents::
    :local:
 
 Overview
 ========
 
 The RoSA (Research on Self-Awareness) Framework is intended to be used as a tool
 for experimenting and evaluating new ways of implementing self-aware
 applications.
 
+This documentation was generated for RoSA version |release| on |today|.
+
 Documentation
 =============
 
 .. toctree::
    :hidden:
 
    Changelog
    Use
    Build
    Dev
    Issues
    Release
    Plan
    CommandGuide/index
 
 :doc:`Use`
   Describes how to create your own software based on RoSA.
 
 :doc:`Build`
   Describes how to build RoSA.
 
 :doc:`Dev`
   Provides basic information for developers on how to contribute to RoSA.
 
 :doc:`Issues`
   Known issues and things to do with the current implementation of RoSA.
 
 :doc:`Release`
   Describes for maintainers how to make a new release of RoSA.
 
 :doc:`Plan`
   Discusses future work and possible ways to develop RoSA.
 
 ..
  :doc:`CommandGuide/index`
  Documentation for RoSA tools.
 
 Changes
 =======
 
 Refer to :doc:`Changelog`.
 
 .. _API_Documentation:
 
 API Documentation
 =================
 
 For details of the provided interface, refer to our `API documentation`_.
 
 .. _API documentation: ../doxygen/html/index.html
 
 Indices and Tables
 ==================
 
 * :ref:`genindex`
 * :ref:`search`