Updates to hosting guide and contribution documentation

docs/tutorials/hosting_guide.rst

@@ -144,7 +144,7 @@ Let's check the connection status. Right click on the tray icon and click on **S
     Network status.
 
 The network status must be **OK** for each user(like in the picture above) otherwise it means that you are not connected to the network.
-If you see something like **ACCESS_DENIED**, it means that you were not authorized to join the network. Please check the :ref:`network-authorization` section.
+If you see something like **ACCESS_DENIED**, it means that you were not authorized to join the network. Please check the section :ref:`network-authorization`
 
 This is it for the ZeroTier network setup. Now everything should be setup to use the multi-user add-on over internet ! You can now follow the :ref:`quickstart` guide to start using the multi-user add-on !
 
@@ -178,7 +178,7 @@ The dedicated server can be run in two ways:
 - :ref:`cmd-line`
 - :ref:`docker`
 
-Note, there are shell scripts to conveniently start a dedicated server via either of these approaches available in the gitlab repository: :ref:`serverstartscripts`
+.. Note:: There are shell scripts to conveniently start a dedicated server via either of these approaches available in the gitlab repository. See section: :ref:`serverstartscripts`
 
 .. _cmd-line:
 
@@ -201,7 +201,7 @@ You can run the dedicated server on any platform by following these steps:
         replication.serve
 
 .. hint::
-    You can also specify a custom **port** (-p), **timeout** (-t), **admin password** (-pwd), **log level(ERROR, WARNING, INFO or DEBUG)** (-l) and **log file** (-lf) with the following optional arguments
+    You can also specify a custom **port** (-p), **timeout** (-t), **admin password** (-pwd), **log level (ERROR, WARNING, INFO or DEBUG)** (-l) and **log file** (-lf) with the following optional arguments
 
     .. code-block:: bash
 
@@ -229,12 +229,27 @@ Launching the dedicated server from a docker server is simple as running:
     docker run -d \
         -p 5555-5560:5555-5560 \
         -e port=5555 \
+        -e log_level=DEBUG \
         -e password=admin \
         -e timeout=1000 \
         registry.gitlab.com/slumber/multi-user/multi-user-server:0.1.0
 
 As soon as the dedicated server is running, you can connect to it from blender by following :ref:`how-to-join`.
 
+You can check your container is running, and find its ID with:
+
+.. code-block:: bash
+
+    docker ps
+
+Logs for the server running in the docker container can be accessed by outputting the following to a log file:
+
+.. code-block:: bash
+
+    docker log your-container-id >& dockerserver.log
+
+.. Note:: If using WSL2 on Windows 10 (Windows Subsystem for Linux), it is preferable to run a dedicated server via regular command line approach (or the associated startup script) from within Windows - docker desktop for windows 10 usually uses the WSL2 backend where it is available.
+
 
 .. _serverstartscripts:
 
@@ -243,14 +258,16 @@ Server startup scripts
 
 Convenient scripts are available in the Gitlab repository: https://gitlab.com/slumber/multi-user/scripts/startup_scripts/
 
-Simply run the relevant script in a shell on the host machine to start a server via replication or docker with one line of code. Choose between the two methods above:
+Simply run the relevant script in a shell on the host machine to start a server with one line of code via replication directly or via a docker container. Choose between the two methods:
 
     .. code-block:: bash
+
         ./start-server.sh
 
 or
 
     .. code-block:: bash
+
         ./run-dockerfile.sh
 
 .. hint::

docs/ways_to_contribute.rst

@@ -21,7 +21,7 @@ In order to help with the testing, you have several possibilities:
 - Test `development branch <https://gitlab.com/slumber/multi-user/-/branches>`_ 
 
 --------------------------
-Filling an issue on Gitlab
+Filing an issue on Gitlab
 --------------------------
 
 The `gitlab issue tracker <https://gitlab.com/slumber/multi-user/issues>`_ is used for bug report and enhancement suggestion.
@@ -35,21 +35,37 @@ Here are some useful information you should provide in a bug report:
 Contributing code
 =================
 
-1. Fork the project into a new repository: https://gitlab.com/yourname/multi-user
+In general, this project follows the `Gitflow Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow>`_.
+The following example suggests how to contribute a feature.
+
+1. Fork the project into a new repository:
+    https://gitlab.com/yourname/multi-user
+
 2. Clone the new repository locally:
-        .. code-block:: bash
-            git clone https://gitlab.com/yourname/multi-user.git
+    .. code-block:: bash
+
+        git clone https://gitlab.com/yourname/multi-user.git
+
 3. Create your own feature branch from the develop branch, using the syntax:
-        .. code-block:: bash
-            git checkout -b feature/yourfeaturename
-    where 'feature/' designates a feature branch, and 'yourfeaturename' is a name of your choosing
+    .. code-block:: bash
+
+        git checkout -b feature/yourfeaturename
+    ...where 'feature/' designates a feature branch, and 'yourfeaturename' is a name of your choosing
+
 4. Pull any recent changes from the 'develop' branch:
-        .. code-block:: bash
-            git pull
+    .. code-block:: bash
+
+        git pull
 5. Add and commit your changes, including a commit message:
-        .. code-block:: bash
-            git commit -am 'Add fooBar'
+    .. code-block:: bash
+
+        git commit -am 'Add fooBar'
 6. Push committed changes to the remote feature branch you created
-        .. code-block:: bash
-            git push origin feature/yourfeaturename
-7. Create a new Pull Request on Gitlab to merge the changes into the develop branch
+    .. code-block:: bash
+
+        git push origin feature/yourfeaturename
+7. Create a new Pull Request on Gitlab
+    merging the changes into the develop branch
+
+.. Note:: For hotfixes, replace 'feature/' with 'hotfix/' and fork from 'master' branch instead of 'develop' branch
+.. Note:: Let's follow the Atlassian `Gitflow Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow>`_, except for one main difference - submitting a pull request rather than merging by ourselves.