Add contributing and developers guide documentation

CONTRIBUTING.rst

@@ -0,0 +1,107 @@
+=================
+How to contribute
+=================
+
+Thank you for considering contributing to SatPy! SatPy's development team
+is made up of volunteers so any help we can get is very appreciated.
+
+Contributions from users are what keep this community going. We welcome
+any contributions including bug reports, documentation fixes or updates,
+bug fixes, and feature requests. By contributing to SatPy you are providing
+code that everyone can use and benefit from.
+
+The following guidelines will describe how the SatPy project structures
+its code contributions from discussion to code to package release.
+
+For more information on contributing to open source projects see
+`GitHub's Guide <https://opensource.guide/how-to-contribute/>`_.
+
+What can I do?
+==============
+
+- Make sure you have a `GitHub account <https://github.com/signup/free>`_.
+- Submit a ticket for your issue, assuming one does not already exist.
+- If you're uncomfortable using Git/GitHub, see
+  `Learn Git Branching <https://learngitbranching.js.org/>`_ or other
+  online tutorials.
+- If you are uncomfortable contributing to an open source project see:
+
+  * `How to Contribute to an Open Source Project on GitHub <https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github>`_
+    video series
+  * Aaron Meurer's `Git Workflow <http://www.asmeurer.com/git-workflow/>`_
+  * `How to Contribute to Open Source <https://opensource.guide/how-to-contribute/>`_
+
+- See what `issues <https://github.com/pytroll/satpy/issues/>`_ already
+  exist. Issues marked
+  `good first issue <https://github.com/pytroll/satpy/labels/good%20first%20issue>`_
+  or `help wanted <https://github.com/pytroll/satpy/labels/help%20wanted>`_
+  can be good issues to start with.
+- Read the :doc:`dev_guide` for more details on contributing code.
+- `Fork <https://help.github.com/articles/fork-a-repo/>`_ the repository on
+  GitHub and install the package in development mode.
+- Update the SatPy documentation to make it clearer and more detailed.
+- Contribute code to either fix a bug or add functionality and submit a
+  `Pull Request <https://help.github.com/articles/creating-a-pull-request/>`_.
+- Make an example Jupyter Notebook and add it to the
+  `available examples <https://github.com/pytroll/pytroll-examples>`_.
+
+What if I break something?
+==========================
+
+Not possible. If something breaks because of your contribution it was our
+fault. When you submit your changes to be merged as a GitHub
+`Pull Request <https://help.github.com/articles/creating-a-pull-request/>`_
+they will be automatically tested and checked against coding style rules.
+Before they are merged they are reviewed by at least one maintainer of the
+SatPy project. If anything needs updating, we'll let you know.
+
+What is expected?
+=================
+
+You can expect the SatPy maintainers to help you. We are all volunteers,
+have jobs, and occasionally go on vacations. We will try our best to answer
+your questions as soon as possible. We will try our best to understand your
+use case and add the features you need. Although we strive to make
+SatPy useful for everyone there may be some feature requests that we can't
+allow if they would require breaking existing features. Other features may
+be best for a different package, PyTroll or otherwise. Regardless, we will
+help you find the best place for your feature and to make it possible to do
+what you want.
+
+We, the SatPy maintainers, expect you to be patient, understanding, and
+respectful of both developers and users. SatPy can only be successful if
+everyone in the community feels welcome. We also expect you to put in as
+much work as you expect out of us. There is no dedicated PyTroll or SatPy
+support team, so there may be times when you need to do most of the work
+to solve your problem (trying different test cases, environments, etc).
+
+Being respectful includes following the style of the existing code for any
+code submissions. Please follow
+`PEP8 <https://www.python.org/dev/peps/pep-0008/>`_ style guidelines and
+limit lines of code to 80 characters whenever possible and when it doesn't
+hurt readability. SatPy follows
+`Google Style Docstrings <http://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html>`_
+for all code API documentation. When in doubt use the existing code as a
+guide for how coding should be done.
+
+
+How do I get help?
+==================
+
+The SatPy developers (and all other PyTroll package developers) monitor the:
+
+- `Mailing List <https://groups.google.com/group/pytroll>`_
+- `Slack chat <https://pytroll.slack.com/>`_ (get an `invitation <https://pytrollslackin.herokuapp.com/>`_)
+- `GitHub issues <https://github.com/pytroll/satpy/issues>`_
+
+How do I submit my changes?
+===========================
+
+Any contributions should start with some form of communication (see above) to
+let the SatPy maintainers know how you plan to help. The larger the
+contribution the more important direct communication is so everyone can avoid
+duplicate code and wasted time.
+After talking to the SatPy developers any additional work like code or
+documentation changes can be provided as a GitHub
+`Pull Request <https://help.github.com/articles/creating-a-pull-request/>`_.
+

doc/source/CONTRIBUTING.rst

@@ -0,0 +1 @@
+../../CONTRIBUTING.rst

doc/source/api/satpy.readers.rst

@@ -164,6 +164,14 @@ satpy\.readers\.hrit\_electrol module
     :undoc-members:
     :show-inheritance:
 
+satpy\.readers\.hrit\_goes module
+---------------------------------
+
+.. automodule:: satpy.readers.hrit_goes
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
 satpy\.readers\.hrit\_jma module
 --------------------------------
 
@@ -308,6 +316,14 @@ satpy\.readers\.safe\_sar\_c module
     :undoc-members:
     :show-inheritance:
 
+satpy\.readers\.scatsat1\_l2b module
+------------------------------------
+
+.. automodule:: satpy.readers.scatsat1_l2b
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
 satpy\.readers\.viirs\_compact module
 -------------------------------------
 

doc/source/dev_guide.rst

@@ -0,0 +1,61 @@
+=================
+Developer's Guide
+=================
+
+The below sections will walk through how to set up a development environment,
+make changes to the code, and test that they work. See the
+:doc:`CONTRIBUTING` section for more information on getting started and
+contributor expectations.
+
+Coding guidelines
+=================
+
+SatPy tries to follow
+`PEP8 <https://www.python.org/dev/peps/pep-0008/>`_ style guidelines for
+all of its python code. We also try to limit lines of code to 80 characters
+whenever possible and when it doesn't hurt readability. SatPy follows
+`Google Style Docstrings <http://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html>`_
+for all code API documentation. When in doubt use the existing code as a
+guide for how coding should be done.
+
+SatPy currently supports Python 2.7 and 3.4+. All code should be written to
+be compatible with these versions.
+
+Development installation
+========================
+
+See the :doc:`install` section for basic installation instructions. When
+it comes time to install SatPy it should be installed from a clone of the git
+repository and in development mode so that local file changes are
+automatically reflected in the python environment. We highly recommend making
+a separate conda environment or virtualenv for development.
+
+First, if you plan on contributing back to the project you should
+`fork the repository <https://help.github.com/articles/fork-a-repo/>`_ and
+clone your fork. The package can then be installed in development by doing::
+
+    pip install -e .
+
+Running tests
+=============
+
+SatPy tests are written using the python :mod:`unittest` module and the tests
+can be executed by running::
+
+    python setup.py test
+
+Documentation
+=============
+
+SatPy's documentation is built using Sphinx. All documentation lives in the
+``doc/`` directory of the project repository. After editing the source files
+there the documentation can be generated locally::
+
+    cd doc
+    make html
+
+The output of the make command should be checked for warnings and errors.
+If code has been changed (new functions or classes) then the API documentation
+files should be regenerated before running the above command::
+
+    sphinx-apidoc -f -T -o source/api ../satpy ../satpy/tests

doc/source/index.rst

@@ -34,6 +34,8 @@ installation.
     composites
     resample
     writers
+    CONTRIBUTING
+    dev_guide
     SatPy API <api/satpy>
 
 

doc/source/install.rst

@@ -37,4 +37,3 @@ To activate this environment use
 .. code-block:: bash
 
     $ source activate satpy-env 
-

satpy/readers/helper_functions.py

@@ -33,7 +33,7 @@
 
 
 def np2str(value):
-    """Convert an np.string_ to str."""
+    """Convert an `numpy.string_` to str."""
     if issubclass(value.dtype.type, np.string_) and not value.shape:
         value = np.asscalar(value)
         if not isinstance(value, str):