Contributing guideline (#17)

* to initiate this branch

* updating dev branch from master (#2)

* Update README.md

* final changes before hollidays...

* added a placeholder for the cnn version

* Condaenv refactor (#1)

* to initiate this branch

* updated condaenv.yml

* Gitignore idea update (#3)

* Update README.md

* final changes before hollidays...

* added a placeholder for the cnn version

* Condaenv refactor (#1)

* to initiate this branch

* updated condaenv.yml

* git ignore idea update

* 2D tests are separated into separate files (#4)

* Release folder structure (#5)

* release folder structure and readme initiated

* release doc name change

* release doc name change again

* release folder structure initiated with dummy files

* Basic CLI, Web object resource fetching extracting (#6)

* WIP:initial commit on cli

* web object download and extract method implemented with test and it is passing, current examples updated with this data accordingly however most examples are exploiting memory till crash, gitignore file updated accordingly

* proper cli structure implemented with working run demo 2D command

* readme todo update (#7)

* Noise2Self Service and initial service package (#8)

* service package added

* noise2self service and its tests added, passing

* Noise2Truth inital implementation (#10)

* drag and drop and button file path picket component created and tested

* typo fix

* gui introduced with noise2self integration

* readme update

* readme update

* cleaning after conflict fix

* style and import fix upon merge of huge pr and fixed condaenv.yml file

* contributing guideline and gplv3 license added

CONTRIBUTING.md

@@ -0,0 +1,82 @@
+## Help us to help you!
+
+Thank you for taking the time to contribute!
+
+* [Suggesting a feature](#suggesting-a-feature)
+* [Filing a bug report](#filing-a-bug-report)
+* [Submitting a pull request](#submitting-a-pull-request)
+
+## Suggesting a feature
+
+We can't think of everything. If you've got a good idea for a feature, then please let us know!
+
+Feature suggestions are embraced, but will often be filed for a rainy day. If you require a feature urgently it's best to write it yourself. Don't forget to share ;)
+
+When suggesting a feature, make sure to:
+
+* Check the code on GitHub to make sure it's not already hiding in an unreleased version ;)
+* Considered if it's necessary in the library, or is an advanced technique that could be separately explained in an example
+* Check existing issues, open and closed, to make sure it hasn't already been suggested
+
+## Filing a bug report
+
+If you're having trouble with PITL, reach us please.
+
+Be as detailed as possible, and be ready to answer questions when we get back to you. Make sure you:
+
+* Tell us which OS you're using
+* List the steps you've taken so far,
+* and any solutions you've tried
+* And a paste/picture of the complete output from the fail might help, too!
+
+## Submitting a pull request
+
+If you've decided to fix a bug, even something as small as a single-letter typo then great! Anything that improves the code/documentation for all future users is warmly welcomed.
+
+If you decide to work on a  requested feature it's best to let us (and everyone else) know what you're working on to avoid any duplciation of effort. You can do this by replying to the original Issue for the request.
+
+When contributing a new example or making a change to a library please keep your code style consistent with ours. We try to stick to the pep8 guidelines for Python (https://www.python.org/dev/peps/pep-0008/).
+
+### Submitting your code
+
+Once you're ready to share your contribution with us you should submit it as a Pull Request.
+
+* Be ready to receive and embrace constructive feedback.
+* Be prepared for rejection; we can't always accept contributions. If you're unsure, ask first!
+
+1. First, start with a new branch on your fork from the target branch
+2. Submit changes to new branch of your fork
+3. Wait for the review and merge.
+4. Upon merge make sure you fetch upstream and update your master branch.
+
+#### Do
+
+* Do use pep8 style guidelines
+* Do comment your code where necessary
+* Do submit only a single example/feature per pull-request
+* Do include a description of what your example is expected to do
+* Do add details of your example to README.md and CONTRIBUTING.md if it is needed
+
+#### Don't
+
+* Don't include any license information in your examples- our repositories are GPLv3 licensed
+* Don't try to do too much at once- submit one or two examples at a time, and be receptive to feedback
+* Don't submit multiple variations of the same example, demonstrate one thing concisely
+
+### Licensing
+
+When you submit code to our libraries, you implicitly and irrevocably agree to adopt the associated licenses. You should be able to find this in the file named `LICENSE.txt`.
+
+We typically use the GPLv3 license.
+
+You can learn more about the GPLv3 license at Wikipedia: https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_3
+
+## Thank you!
+
+If you have any questions, concerns or comments about these guidelines, please get in touch.
+
+Above all else, we hope you enjoy yourself, learn things and make and share great contributions.
+
+Happy hacking!
+
+-- PITL team