Merge branch 'master' of github.com:glpi-project/docdev

README.md

@@ -1,19 +1,18 @@
 # GLPi's developper documentation
 
-[Show GLPi Developer Documentation online!](http://glpi-developer-documentation.readthedocs.io/en/latest) [![Build Status](https://readthedocs.org/projects/glpi-developer-documentation/badge/?version=latest)](http://glpi-developer-documentation.readthedocs.io/en/latest/?badge=latest)
+[![Build Status](https://readthedocs.org/projects/glpi-developer-documentation/badge/?version=latest)](http://glpi-developer-documentation.readthedocs.io/en/latest/?badge=latest)
 
 Current documentation is built on top of [Sphinx documentation generator](http://sphinx-doc.org/). It is released under the terms of the <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons BY-NC-ND 4.0 International License</a>.
 
 ## Run it!
 
-You'll have to install [Python Sphinx](http://sphinx-doc.org/) 1.3 minimum, and Python Markdown module (`recommonmark`).
+You'll just have to install [Python Sphinx](http://sphinx-doc.org/), it is generally available in distributions repositories for Linux.
 
-If your distribution does not provide this version, you could use a `virtualenv`:
+If your distribution does not provide it, you could use a `virtualenv`:
 ```
 $ virtualenv /path/to/virtualenv/files
 $ /path/to/virtualenv/bin/activate
 $ pip install sphinx
-$ pip install recommonmark
 ```
 
 Once all has been successfully installed, just run the following to build the documentation:

source/codingstandards.rst

@@ -16,6 +16,15 @@ Indentation
        // level 1
    // base level
 
+Spacing
+-------
+
+We've adopted "french spacing" rules in the code. The rule is:
+
+* for *simple* punctuation (``,``, ``.``): use *one space after* the punctuation sign;
+* for *double* punctuation (``!``, ``?``, ``:``): use *one space after and one space before* the punctuation sign.
+
+Of course, this rules only aplies on the source code, not on the strings (translatable strings, comments, ...)!
 
 Control structures
 ------------------
@@ -34,7 +43,7 @@ Multiple conditions in several idented lines
    if ($a==$b
       || ($c==$d && $e==$f)) {
      ...
-   } elseif {
+   } else if {
      ...
    }
    

source/plugins.rst

@@ -181,7 +181,7 @@ The plugin directory structure should look like the following:
 Versionning
 ^^^^^^^^^^^
 
-We recommand you to use `semantic versionning <http://semver.org/>` for you plugins. You may find existing plugins that have adopted another logic; some have reasons, others don't... Well, it is up to you finally :-)
+We recommand you to use `semantic versionning <http://semver.org/>`_ for you plugins. You may find existing plugins that have adopted another logic; some have reasons, others don't... Well, it is up to you finally :-)
 
 Whatever the versionning logic you adopt, you'll have to be consistent, it is not easy to change it without breaking things, once you've released something.
 

source/reviewprocess.rst

@@ -15,6 +15,6 @@ Here is the process you must follow when you are reviewing a PR.
 
   * If some new methods are added, or if the request made important changes in the code, you should ask the developer to write some more unit tests
 
-6. A PR can be merged back if two developers approved it, or if one developer approved it more than one day ago,
-7. A bugfix PR that has been merged into the `xx/bugfixes` branch must be reported on the `master` branch. If the `master` already contains many changes, you may have to change some code before doing this. f changes are consequent, maybe should you open a new PR against the `master` branch for it,
+6. A PR can be merged if two developers approved it, or if one developer approved it more than one day ago,
+7. A bugfix PR that has been merged into the `xx/bugfixes` branch must be reported on the `master` branch. If the `master` already contains many changes, you may have to change some code before doing this. If changes are consequent, maybe should you open a new PR against the `master` branch for it,
 8. Say thanks to the contributor :-)

source/sourcecode.rst

@@ -1,7 +1,7 @@
 Source Code management
 ======================
 
-GLPi source code management is handled by `GIT <https://en.wikipedia.org/wiki/Git>`_ and hosted on `GitHub <(https://github.com/glpi-project/glpi>`_.
+GLPi source code management is handled by `GIT <https://en.wikipedia.org/wiki/Git>`_ and hosted on `GitHub <https://github.com/glpi-project/glpi>`_.
 
 In order to contribute to the source code, you will have to know a few things about Git and the development model we follow.
 
@@ -39,7 +39,7 @@ In a short form, here is the workflow we'll follow:
 * fork, create a specific branch, and hack
 * open a :abbr:`PR (Pull Request)`
 
-Each bug will be fixed in a branch that came from the correct `bugfixes` branch. Once merged back to the branch, developper must backport the fixes in the `master`; just with a simple cherry-pick for simple cases, or opening another pull request if changes are huge.
+Each bug will be fixed in a branch that came from the correct `bugfixes` branch. Once merged into the requested branch, developper must report the fixes in the `master`; with a simple cherry-pick for simple cases, or opening another pull request if changes are huge.
 
 Each feature will be hacked in a branch that came from `master`, and will be merged back to `master`.
 
@@ -56,7 +56,7 @@ Just work with a:
 
 A directory named ``glpi`` will bre created where you've issued the clone.
 
-Then - if you did not alreay - you will have to create a fork of the repository on your github account; using the `Fork` button from the `GLPi's Github page <https://github.com/glpi-project/glpi/>`_. This will take a few moments, and you will have a repository created, `{you user name}/glpi - forked from glpi-project/glpi`.
+Then - if you did not already - you will have to create a fork of the repository on your github account; using the `Fork` button from the `GLPi's Github page <https://github.com/glpi-project/glpi/>`_. This will take a few moments, and you will have a repository created, `{you user name}/glpi - forked from glpi-project/glpi`.
 
 Add your fork as a remote from the cloned directory:
 
@@ -68,7 +68,7 @@ You can replace `my_fork` with what you want but `origin` (just remember it); an
 
 A basic good practice using Git is to create a branch for everything you want to do; we'll talk about that in the sections below. Just keep in mind that you will publish your branches on you fork, so you can propose your changes.
 
-Whan you open a new pull request, it will be reviewed by one or more member of the community. If you're asked to make some changes, just commit again on your local branch, push it, and you're done; the pull request will be automatically updated.
+When you open a new pull request, it will be reviewed by one or more member of the community. If you're asked to make some changes, just commit again on your local branch, push it, and you're done; the pull request will be automatically updated.
 
 Bugs
 ^^^^