Add contributing and code of conduct to docs

docs/contributing.rst

@@ -0,0 +1,14 @@
+============
+Contributing
+============
+
+Contributions are welcome, and they are greatly appreciated! Every
+little bit helps, and credit will always be given.
+
+.. toctree::
+    :numbered:
+    :maxdepth: 2
+
+    contributor_types
+    contributor_setup
+    contributor_guidelines

docs/contributor_code_of_conduct.rst

@@ -0,0 +1,2 @@
+
+.. include:: ../CODE_OF_CONDUCT.rst

docs/contributor_guidelines.rst

@@ -0,0 +1,96 @@
+
+Contributor Guidelines
+----------------------
+
+Pull Request Guidelines
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Before you submit a pull request, check that it meets these guidelines:
+
+1. The pull request should include tests.
+2. If the pull request adds functionality, the docs should be updated. Put
+   your new functionality into a function with a docstring.
+3. The pull request should work for Python 3.6 and 3.7, and Travis CI.
+4. Check https://travis-ci.com/opacam/Cohen3/pull_requests to ensure the tests
+   pass for all supported Python versions and platforms.
+
+Coding Standards
+~~~~~~~~~~~~~~~~
+
+* PEP8
+* Write new code in Python 3.
+
+Docstrings
+~~~~~~~~~~
+
+Every module/class/method/function needs a docstring, so use the following
+keywords when relevant:
+
+- ``.. versionadded::`` to mark the version in which the feature was added.
+- ``.. versionchanged::`` to mark the version in which the behaviour of the
+  feature was changed.
+- ``.. note::`` to add additional info about how to use the feature or related
+  feature.
+- ``.. warning::`` to indicate a potential issue the user might run into using
+  the feature.
+
+Examples::
+
+    def my_new_feature(self, arg):
+        """
+        New feature is awesome
+
+        .. versionadded:: 0.8.3
+
+        .. note:: This new feature will likely blow your mind
+
+        .. warning:: Please take a seat before trying this feature
+        """
+
+Will result in:
+
+    def my_new_feature(self, arg):
+        New feature is awesome
+
+        .. versionadded:: 0.8.3
+
+        .. note:: This new feature will likely blow your mind
+
+        .. warning:: Please take a seat before trying this feature
+
+
+When referring to other parts of the api use:
+
+- ``:mod:`~coherence.module``` to refer to a module
+- ``:class:`~coherence.module.Class``` to refer to a class
+- ``:attr:`~coherence.module.Class.attribute``` to refer to a attibute
+- ``:meth:`~coherence.module.Class.method``` to refer to a method
+
+Obviously replacing `module`, `Class`, `attribute` and `method` with their
+real name, and using using '.' to separate modules referring to imbricated
+modules, e.g::
+
+    :mod:`~coherence.upnp.core.device`
+    :class:`~coherence.upnp.core.device.Device`
+    :attr:`~coherence.upnp.core.device.Device.services`
+    :meth:`~coherence.upnp.core.device.Device.parse_device`
+
+Will result in:
+
+    :mod:`~coherence.upnp.core.device`
+    :class:`~coherence.upnp.core.device.Device`
+    :attr:`~coherence.upnp.core.device.Device.services`
+    :meth:`~coherence.upnp.core.device.Device.parse_device`
+
+To build your documentation, enter into docs folder and run::
+
+    $ make html
+
+If you updated your Cohen3 install, and have some trouble compiling docs, run::
+
+    $ make clean
+    $ make html
+
+The docs will be generated in ``docs/_build/html``. For more information on
+docstring formatting, please refer to the official
+`Sphinx Documentation <http://sphinx-doc.org/>`_.

docs/contributor_setup.rst

@@ -0,0 +1,55 @@
+
+Setting Up the Code for Local Development
+-----------------------------------------
+
+Here's how to set up `Cohen3` for local development.
+
+1. Fork the `Cohen3` repo on GitHub.
+2. Clone your fork locally::
+
+    $ git clone git@github.com:your_name_here/Cohen3.git
+
+3. Install your local copy into a virtualenv. Assuming you have `pyenv
+   <https://github.com/pyenv/pyenv>`_ installed, this is how you set up your
+   fork for local development::
+
+    $ CONFIGURE_OPTS=--enable-shared pyenv install 3.7-dev
+    $ CONFIGURE_OPTS=--enable-shared pyenv virtualenv 3.7-dev cohen3
+    $ cd Cohen3/
+    $ pyenv activate cohen3
+    $ pip install pipenv
+    $ pipenv install
+    $ pip install -e .[dev]
+
+4. Create a branch for local development::
+
+    $ git checkout -b name-of-your-bugfix-or-feature
+
+Now you can make your changes locally.
+
+5. When you're done making changes, check that your changes pass the tests::
+
+    $ pycodestyle coherence --statistics --ignore=E402
+    $ pylint -E coherence --rcfile=.pylintrc
+    $ nosetests --with-coverage --cover-erase --cover-package=coherence --cover-html
+
+6. Check that the test coverage hasn't dropped:
+
+    The last command of the above point (nosetests), will print a report at the
+    end of the tests (or you can check the results via your web browser: check
+    the created folder "cover" and visualize the index.htm file for a nice
+    report). Check that coverage percent against the coverage before the
+    changes you made.
+
+    :Note: You also can check the coverage once you submitted the pull requests
+           and travis tests are done (but this, probably, it will be  slower
+           than do it manually from your os, because you can skip some steps
+           that travis cannot skip).
+
+7. Commit your changes and push your branch to GitHub::
+
+    $ git add .
+    $ git commit -m "Your detailed description of your changes."
+    $ git push origin name-of-your-bugfix-or-feature
+
+8. Submit a pull request through the GitHub website.

docs/contributor_types.rst

@@ -0,0 +1,76 @@
+
+Types of Contributions
+----------------------
+
+You can contribute in many ways:
+
+Fix Cohen3 backends (plugin)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Right now some of the plugins are outdated and should be reviewed/updated.
+
+Add more tests
+~~~~~~~~~~~~~~
+
+There will be great if we can increase the coverage of our source code. Most of
+the backends hasn't the corresponding tests.
+
+
+Report Bugs
+~~~~~~~~~~~
+
+Report bugs at https://github.com/opacam/Cohen3/issues.
+
+If you are reporting a bug, please include:
+
+* Your operating system name and version.
+* Any details about your local setup that might be helpful in troubleshooting.
+* If you can, provide detailed steps to reproduce the bug.
+* If you don't have steps to reproduce the bug, just note your observations in
+  as much detail as you can. Questions to start a discussion about the issue
+  are welcome.
+
+Fix Bugs
+~~~~~~~~
+
+Look through the GitHub issues for bugs. Anything tagged with "bug"
+is open to whoever wants to implement it.
+
+Implement Features
+~~~~~~~~~~~~~~~~~~
+
+Look through the GitHub issues for features. Anything tagged with "enhancement"
+and "please-help" is open to whoever wants to implement it.
+
+Please do not combine multiple feature enhancements into a single pull request.
+
+Write Documentation
+~~~~~~~~~~~~~~~~~~~
+
+Cohen3 could always use more documentation, whether as part of the
+official Cohen3 docs, in docstrings, or even on the web in blog posts,
+articles, and such.
+
+If you want to review your changes on the documentation locally, you can do::
+
+    pip install -e .[doc]
+    cd docs
+    make html
+
+This will compile the documentation, open it in your browser and start
+watching the files for changes, if the pull request is accepted by the Cohen3
+team, it will be compiled and posted automatically at the branch gh-pages
+whenever the pull request is merged into the master branch.
+
+Submit Feedback
+~~~~~~~~~~~~~~~
+
+The best way to send feedback is to file an issue at
+https://github.com/opacam/Cohen3/issues.
+
+If you are proposing a feature:
+
+* Explain in detail how it would work.
+* Keep the scope as narrow as possible, to make it easier to implement.
+* Remember that this is a volunteer-driven project, and that contributions
+  are welcome :)

docs/index.rst

@@ -62,6 +62,8 @@ Table of Contents
     cli
     backends
     source/coherence
+    contributing
+    contributor_code_of_conduct
     changelog
 
 .. automodule:: mod