Major updates to CONTRIBUTING.md file

In addition to Code Style section, further subsections have been added
such as:

	* Creating an Issue
	* Submitting a Pull Request
	* Running Tests Locally
	* Package Versioning

Some sections anticipate adoption of certain practises that have not
been implemented yet, such as CHANGELOG, but this should be in place in
due course. Therefore this commit links to #129

Closes #127

CONTRIBUTING.md

@@ -1,8 +1,76 @@
-# Conventions for pushing code to `snmachine`
+# Contributing to `snmachine`
 
-## Import Conventions
+The goal of this guide is to help users contribute to `snmachine` as quickly and as easily possible.
 
-Conventions from Pep8 (https://pep8.org/).
+# Table of contents
+1. [Creating an Issue](#issues)
+2. [Submitting a Pull Request](#prs)
+3. [Code Style](#style)
+4. [Running Tests Locally](#testing)
+5. [Package Versioning](#version)
+
+<a name="issues"></a>
+## Creating an Issue
+
+To report bugs, request features, or ask questions about the structure of the
+code, please [open an issue](https://github.com/LSSTDESC/snmachine/issues)
+
+### Bugs
+
+For program crash, or to report a specific error, please file an issue by
+opening a [Bug Report](https://github.com/LSSTDESC/snmachine/issues/new?assignees=&labels=bug&template=BUG.md&title=%5BBUG%5D)
+
+Follow instructions contained in the Github issue template in order to provide
+enough detail that the `snmachine` developers can tackle the problem.
+
+### Feature Requests
+
+For feature requests or enhancement suggestions, please file a [Feature Request issue](https://github.com/LSSTDESC/snmachine/issues/new?assignees=&labels=feature&template=feature_request.md&title=%5BFEATURE%5D)
+
+A detailed explanation of what idea is being proposed should be put in the body
+of the issue. The title can be appended with `[RFC]` to signify a "Request for
+Comments" is desired on how best to incorporate said feature or to discuss at
+length `[RFD]` may be used instead as a marker for "Request for Discussion"
+
+### General
+
+If the issue is general, perhaps just a question, or minor fix required, a plain
+issue would be appropriate. These can be opened with a [normal issue](https://github.com/LSSTDESC/snmachine/issues/new)
+
+<a name="prs"></a>
+## Submitting a Pull Request
+
+We welcome [pull requests](https://help.github.com/articles/about-pull-requests/) from anyone
+interested in contributing to `snmachine`. This section describes best practices
+for submitting PRs to this project.
+
+If you are interested in making changes that impact the way `snmachine` works,
+please [open an issue](#issues) proposing what you would like to work on before
+you spend time creating a PR.
+
+To submit a PR, please follow these steps:
+
+0. [Create an issue](#issues) and make note of the issue number
+1. Fork `snmachine` to your GitHub account
+2. Create a branch from `dev` on your fork with the convention of: `issue/<issue-number>/one-or-two-word-token-description-of-issue`
+	- If you are working on a `[FEATURE]`, please branch from `dev` with the
+	    convention of: `feauture/<issue-number>/one-or-two-word-token-description-of-issue`, this is to allow for issues to be raised on specific features also, which would then have the convention of:
+	    `feature/<original-issue-number>/issue/<new-issue-number>/short-description`(where issues on a particular feautre would be branched from the feature-branch in question)
+
+3. Make changes, add code etc and open a PR
+
+Please ensure your branch is up-to-date with `dev` branch by rebasing your changes. If unsure how to approach this, make a comment in the PR that has been opened.
+
+<a name="style"></a>
+## Code Style
+
+Much of our code style follows the convention defined in [PEP8](https://pep8.org/).
+
+In addition, codebase guidelines outlined in the [LSST Developer Guide](https://developer.lsst.io/python/style.html)
+and in the [LSST DESC Coding Guidelines](https://confluence.slac.stanford.edu/display/LSSTDESC/Interim+LSST+DESC+Paper+Tracking?preview=/217813295/244908471/LSST%20DESC%20Coding%20Guidelines%20v1.1.pdf)
+document
+
+#### Import Conventions
 
 Imports should be grouped in the following order:
 
@@ -12,17 +80,17 @@ Imports should be grouped in the following order:
 
 There should be a blank line between each group of imports.
 
-## Naming Conventions
+### Naming Conventions
 
 * class names -> PascalCase
 * function and variable names -> snake_case
 * function names -> start with descriptive verb (eg. get, compute, fit, load)
 * hidden function names -> same as function names but starting with `_`
 * descriptive names that minimize the number of necessary comments
 
-## Documentation Conventions
+### Documentation Conventions
 
-### Functions
+#### Functions
 
 They should follow NumPy Style (https://numpydoc.readthedocs.io/en/latest/format.html).
 
@@ -98,3 +166,47 @@ def foo(var1, var2, long_var_name='hi'):
 
     pass
 ```
+
+<a name="testing"></a>
+## Running Tests Locally
+
+We use Azure Pipelines to automatically run tests and other
+automated checks on every PR commit and merge to `master` and `dev` branches.
+
+However, if you would like to run the test suite locally, one can simply run:
+```i{bash}
+cd /path/to/snmachine/ && pytest -vs tests/
+```
+<a name="version"></a>
+## Package Versioning
+
+### Version Format
+
+We follow semantic versioning for `snmachine` releases, `MAJOR`.`MINOR`.`PATCH`:
+
+* the `MAJOR` version will be updated when incompatible API changes are made,
+* the `MINOR` version will be updated when functionality is added in a
+backwards-compatible manner, and
+* the `PATCH` version will be updated when backwards-compatible bug
+fixes are made.
+
+For more details, see https://semver.org/
+
+Furthermore, `snmachine` adopts the release formatting of
+[PEP440](https://www.python.org/dev/peps/pep-0440/)
+
+### Release Planning
+
+The authors of this package have adopted [milestones on github](https://help.github.com/en/articles/about-milestones) as a vehile to
+scope and schedule upcoming releases.  The main goal for a release is written in
+the milestone description.  Then, any ideas, specific functionality, bugs, etcs
+submitted as [issues](https://help.github.com/en/articles/about-issues)
+pertinent to that goal are tagged for that milestone.  Goals for milestone are
+discussed openly via a github issue.
+
+Past and upcoming releases can be seen on the  [snmachine milestones
+page](https://github.com/LSSTDESC/snmachine/milestones).
+
+For details on how the API has altered across versions, please refer to the
+[`CHANGELOG.md`](https://www.github.com/LSSTDESC/snmachine/CHANGELOG.md) file,
+which documents changes made and where breaking changes would have been introduced.