Merge branch 'master' of github.com:rdmorganiser/rdmo

Author: jochenklar

NOTICE

@@ -18,7 +18,7 @@ See the License for the specific language governing permissions and
 limitations under the License.
 
 
-This code contains code derived from several other projects, which are distibuted
+This code contains code derived from several other projects, which are distributed
 under the following licenses:
 
 

docs/configuration/index.rst

@@ -6,7 +6,7 @@ The RDMO application uses the `Django settings <https://docs.djangoproject.com/e
 * ``config/settings/base.py``, which is part of the git repository and maintained by the RDMO development team.
 * ``config/settings/local.py``, which is ignored by git and should be edited by you.
 
-As part of the installation ``config/settings/local.py`` should be creted from the template ``config/settings/sample.local.py``.
+As part of the installation ``config/settings/local.py`` should be created from the template ``config/settings/sample.local.py``.
 
 While technically the local settings file ``config/settings/local.py`` can be used to override all of the settings in ``config/settings/sample.local.py``, it should be used to customize the settings already available in ``config/settings/sample.local.py``.
 

docs/installation/setup.rst

@@ -10,7 +10,7 @@ You can use ``config/settings/sample.local.py`` as template, i.e.:
     cp config/settings/sample.local.py config/settings/local.py    # on Linux or macOS
     copy config\settings\sample.local.py config\settings\local.py  # on Windows
 
-Most of the settings of your RDMO instance are specified in this file. The different settings are explained in detail :doc:`later in the documentation </configuration/index>`. For a minimal configuration, you need to set ``DEBUG = True`` to see verbose error messages and serve static files, and ``SECRET_KEY`` to a long random string, which you will keep secret. Your database connection is configured using the ``DATABASES`` variable. Database configuration is covered :doc:`later in the documentation </configuration/databases>`. If no ``DATABASE``. If no ``DATABASE`` setting is given ``sqlite3`` will be used as database backend.
+Most of the settings of your RDMO instance are specified in this file. The different settings are explained in detail :doc:`later in the documentation </configuration/index>`. For a minimal configuration, you need to set ``DEBUG = True`` to see verbose error messages and serve static files, and ``SECRET_KEY`` to a long random string, which you will keep secret. Your database connection is configured using the ``DATABASES`` variable. Database configuration is covered :doc:`later in the documentation </configuration/databases>`. If no ``DATABASE`` setting is given ``sqlite3`` will be used as database backend.
 
 Then, initialize the database of the application, using:
 

docs/management/index.rst

@@ -10,7 +10,7 @@ A freshly installed instance of RDMO is not very useful without a questionaire t
 
 A full representation is shown :doc:`on a different page </development/figures>`. Here, we explain the different parts of the data model. Each section has a link to a more detailed explanation how to create and edit the relevant elements.
 
-For most users, the structured interview will be the most visible part of RDMO. It is configured using **catalogs**, **sections**, **subsections**, **questionsets**, and **questions**. A single installation of RDMO can have several catalogs. When creating a new project, a user can select one of these catalogs to be used with this project. A catalog has a number of sections, which themselves have subsections. Questions can be directly added to subsections, which will result in a single question on a singe page of the interview. Alternatively, they can be organized into question sets. A question has a text, which will be shown in bold to the user and an optional help text. It also has a widget type, which determines which interface widget is presented to the user (e.g. text field, select field, radio buttons). The questionnaire is configured under ``/questions`` available in the management menu. More documentation about the questions management can be found :doc:`here </management/questions>`.
+For most users, the structured interview will be the most visible part of RDMO. It is configured using **catalogs**, **sections**, **subsections**, **questionsets**, and **questions**. A single installation of RDMO can have several catalogs. When creating a new project, a user can select one of these catalogs to be used with this project. A catalog has a number of sections, which themselves have subsections. Questions can be directly added to subsections, which will result in a single question on a single page of the interview. Alternatively, they can be organized into question sets. A question has a text, which will be shown in bold to the user and an optional help text. It also has a widget type, which determines which interface widget is presented to the user (e.g. text field, select field, radio buttons). The questionnaire is configured under ``/questions`` available in the management menu. More documentation about the questions management can be found :doc:`here </management/questions>`.
 
 The **domain model** is the central part of the data model and connects the questions from the questionnaire with the user input. It is organized as a tree-like structure. Every piece of information about a user's project is represented by an **attribute**. In this sense these attributes can be compared to a variable in source code. Attributes are the leaves of the domain model tree and can be organized into **entities**, much like files are organized along directories on a disk. Every question must have an attribute and every question set must have an entity connected to it. An example would be the attribute with the path ``project/schedule/project_start`` for the start date of the project. The attribute itself has the key ``project_start`` and resides in the entity ``schedule``, which itself is located in the entity ``project``.
 
@@ -24,9 +24,9 @@ Attributes can further be connected to **option sets** consisting of **options**
 
 **Views** allow for custom DMP templates in RDMO. To this purpose every view has a template which can be edited using the Django template sytax, which is based on HTML. Views have also a title and a help text to be shown in the project overview. Views are configured under ``/views`` available in the management menu. More documentation about editing views can be found :doc:`here </management/views>`.
 
-After filling out the interview the user will be presented with follow up **tasks** based on his/her answers. A task has a title and a text. **Time frames** can be added to tasks, which themselves are evaluating attributes of the value type "datetime", to use answers like the beginning or the end of a project to compute meaningful tasks. Most of the time tasks will have a condition connected to them, to determine if this task is needed for a particular project or not. Tasks configured under ``/tasks`` available in the management menu. More documentation about editing views can be found :doc:`here </management/tasks>`.
+After filling out the interview the user will be presented with follow up **tasks** based on his/her answers. A task has a title and a text. **Time frames** can be added to tasks, which themselves are evaluating attributes of the value type "datetime", to use answers like the beginning or the end of a project to compute meaningful tasks. Most of the time tasks will have a condition connected to them, to determine if this task is needed for a particular project or not. Tasks configured under ``/tasks`` are available in the management menu. More documentation about editing views can be found :doc:`here </management/tasks>`.
 
-The different elements of the RDMO datamodel have various parameters, which controll their behavior in RDMO and can be configured using the different management pages, which are decribed on the following pages. In addition, all elements contain a set of common parameters:
+The different elements of the RDMO datamodel have various parameters, which control their behavior in RDMO and can be configured using the different management pages, which are decribed on the following pages. In addition, all elements contain a set of common parameters:
 
 * An URI Prefix to identify the entity who created this element.
 * A key which is the internal identifier for this element.