Add Contribution guidelines (#294)

* [DOC] first partial draft of contribution guidelines

added cloning, questions, bug reports and feature requests

Relates to issue #287 and epic #270

* [DOC]  draft of proper contribution guidelines

docstrings, formatting (pep8), testing

Relates to issue #287 and epic #270

* [DOC]  expanded guidelines draft: 3 rules

Relates to issue #287 and epic #270

* [DOC]  reorganized sections

Relates to issue #287 and epic #270

* [DOC]  edited for brevity

Relates to issue #287 and epic #270

* Rename CONTRIBUTION.md to CONTRIBUTING.md

This is now the same file name used by PyVista and I think generally is the standard name.

* Rename test/CONTRIBUTING.md to CONTRIBUTING.md

Move CONTRIBUTING.md to the top level, which I think is the standard approach.

* Remove clone instructions and point PR's to master

The most important point is that we want new contributions to make PR's to master.
The README already explains how to clone, and it's nothing different than any other GitHub project. I think we have to assume some proficiency with git and GitHub here.

* Clarify PR section heading and separate checklist

* Make Questions description more concise

* Say to search for related questions first

Also link directly to issues

* [DOC] Updated bug report issue template

Relates to epic issue #270

* Shortened and clarified bug reporting

- Removed mention of "appropriate labeling" (since I am not aware of guidelines yet for this) and said to label as a bug.
- Linked directly to bug issue template 
[skip ci]

* [DOC] First draft of pull request template

Relates to epic issue #270

* [DOC] adds question issue template

Relates to epic issue #270

* [DOC] Edit of Alex Z for contribution guidelines

* [DOC] Edited pull request guidelines

* Remove randomly inserted link

* Extend the PR requirements

Most importantly I think it should be clear that tests should not be entirely trivial.

* Link to docstring guidelines in PR checklist

* Separate test requirements into a PR check box

* Correct list item indentation

* Clarify test requirements

* Paste same checklist from Contributing.md

* Refer to PR template for PR checklist

* Attempt to fix list formatting

* Another attempt to make Codacy happy with the list

Co-authored-by: Alexander G. Zimmerman <alex.g.zimmerman@gmail.com>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -8,14 +8,16 @@ assignees: ''
 ---
 
 **Describe the bug**
-A clear and concise description of what the bug is.
+A clear and concise description of what the bug is. Include error messages / 
+tracebacks. If useful include screenshots.
 
 **To Reproduce**
-Steps to reproduce the behavior:
-1. Go to '...'
-2. Click on '....'
-3. Scroll down to '....'
-4. See error
+Provide detailed steps to reproduce the behavior:
+
+1.
+2.
+3.
+...
 
 **Expected behavior**
 A clear and concise description of what you expected to happen.
@@ -24,15 +26,11 @@ A clear and concise description of what you expected to happen.
 If applicable, add screenshots to help explain your problem.
 
 **Desktop (please complete the following information):**
- - OS: [e.g. iOS]
- - Browser [e.g. chrome, safari]
- - Version [e.g. 22]
-
-**Smartphone (please complete the following information):**
- - Device: [e.g. iPhone6]
- - OS: [e.g. iOS8.1]
- - Browser [e.g. stock browser, safari]
- - Version [e.g. 22]
+  * OS: (e.g. iOS)
+  * GemPy Version
+    * if installed via pip: provide GemPy version (e.g. 2.0.1)
+    * if cloned from GitHub: provide Git commit id (e.g. 839bf85f)
+  * Jupyter Version (if applicable)
 
 **Additional context**
 Add any other context about the problem here.

.github/ISSUE_TEMPLATE/question.md

@@ -0,0 +1,10 @@
+---
+name: Question
+about: Ask a question about GemPy
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**What is your question?**

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,15 @@
+# Description
+Please include a summary of the changes.
+
+Relates to <issue>
+
+# Checklist
+- [ ] My code follows the [PEP 8 style guidelines](https://www.python.org/dev/peps/pep-0008/).
+- [ ] My code uses type hinting for function and method arguments and return values.
+- [ ] My code contains descriptive and helpful docstrings 
+which are formatted per the [Google Python Style Guidelines](http://google.github.io/styleguide/pyguide.html).
+- [ ] I have created tests which entirely cover my code.
+- [ ] The test code either 1. demonstrates at least one valuable use case (e.g. integration tests) 
+or 2. verifies that outputs are as expected for given inputs (e.g. unit tests).
+- [ ] New and existing tests pass locally with my changes.
+

CONTRIBUTING.md

@@ -0,0 +1,103 @@
+# Contributing
+
+We welcome and encoruage everyone to contribute to GemPy! 
+Contributions can be questions, bug reports, feature requests and new code. 
+Here is how to get started.
+
+## Issues 
+
+### Questions
+
+For questions about GemPy (e.g. its applications, functionality, and usage), 
+please [search the existing issues for related questions](https://github.com/cgre-aachen/gempy/issues).
+If your question has not already been asked, then [make a new issue](https://github.com/cgre-aachen/gempy/issues/new/choose).
+
+### Reporting Bugs
+
+Please report bugs on the [issue page using the bug report template](https://github.com/cgre-aachen/gempy/issues/new?assignees=&labels=&template=bug_report.md&title=) and label the issue as a bug.
+The template asks essential questions for you to answer so that we can to understand, reproduce, and fix the bug. 
+Be verbose!
+Whenever possible, provide tracebacks and/or error messages, screenshots, and sample code or other files.
+
+### Feature Requests
+
+We encourage users to submit ideas for improvements to the GemPy project. For
+this please create an issue on the
+ [issue page](https://github.com/cgre-aachen/gempy/issues) with the *Feature 
+ Request* template and label. Please make sure to use a descriptive title and to
+ provide ample background information to help us implement that functionality
+ in the future.
+
+## Contributing New Code
+
+Any code contributions are welcome, 
+whether fixing a typo or bug,
+adding new post-processing/plotting functionality,
+improve core functionality,
+or anything that you think should be in the repository. 
+
+Contributions should address an open issue (either a bug or a feature request).
+If you have found a new bug 
+or have an idea or a new feature, 
+then please [open the issue](https://github.com/cgre-aachen/gempy/issues/new/choose) 
+for discussion and link to that issue in your pull request.
+
+### Python code guidelines
+We aim to follow particular Python coding guidelines to improve the sustainability and positive impact of this community project:
+
+- Follow [The Zen of Python](https://www.python.org/dev/peps/pep-0020/), most importantly "readability counts" when writing Python code.
+- Adhere to the [Style Guide for Python Code (PEP8)](https://www.python.org/dev/peps/pep-0008/).
+- Write thorough and effective documentation: 
+Make a docstring for each module, function, class, and method, 
+all following [PEP 257](https://www.python.org/dev/peps/pep-0257/) for high-level guidelines
+and [Google Python Style Guidelines](http://google.github.io/styleguide/pyguide.html) for Syntax. 
+**Example function documentation:**
+```python
+def func(arg1: int, arg2: float) -> int:
+    """A concise one line summary of the function.
+    
+    Additional information and description of the function, if necessary. This
+    can be as long and verbose as you think is necessary for other users and 
+    developers to understand your functionality.
+    
+    Args:
+        arg1 (int): Description of the first argument.
+        arg2 (float): Description of the second argument. Please use hanging 
+            indentation for multi-line argument descriptions.
+    
+    Returns:
+        (int) Description of the return value(s)
+    """
+    return 42
+```
+- The code should explain the *what* and *how*. Add inline comments to explain the *why*.
+If an inline comment seems to be needed, consider first making the code more readable.
+For all comments, follow [PEP 8](https://www.python.org/dev/peps/pep-0008/).
+- Test every line of code. Untested code is dead code.
+
+### Licensing
+
+All contributed code will be licensed under 
+[a LGPL-3 license](https://github.com/cgre-aachen/gempy/blob/master/LICENSE).
+If you did not write the code yourself, 
+it is your responsibility to ensure that the existing license is compatible 
+and included in the contributed files. 
+In general we discourage contributing third party code.
+
+### Testing
+
+Our test suite uses [`pytest`](https://docs.pytest.org/). 
+You should be familiar with `pytest` before contributing.
+Please run all tests locally before creating a pull request. 
+You can do this by running `pytest` via your terminal in your GemPy folder:
+```bash
+cd ./path/to/gempy
+pytest
+```
+All tests are located in the `test` folder and its subfolders.  
+All contributed code must include test code in the pull request.
+
+### Pull Requests
+
+All contributions are made via pull requests (PR's) to the master branch. 
+You must complete the checklist in the [PR template](https://github.com/cgre-aachen/gempy/blob/master/.github/PULL_REQUEST_TEMPLATE.md) before we will review the PR and consider merging your contribution.