Create CONTRIBUTING guidelines

[boulund]

We should consider adding a CONTRIBUTING (plain text file) in the root of the repo that will contain contributing guidelines for BACTpipe.

We should include a small checklist for important things to double-check before merging the develop branch to master.

Here is some text I copy-pasted from stag-mwc that can serve as an inspiration:

Issue tracker
We use the issue tracker in Github. Submit issues for things such as bug reports, feature requests, or general improvement discussion topics.

Submitting changes
The main branch of StaG-mwc should always be stable and reliable. All development should be based on the develop branch. Please create new feature branches from the develop branch. The develop branch is then merged into the master branch when enough improvements have accrued. The typical procedure to develop new features or fix bugs in StaG-mwc looks something like this:

Fork or clone the repository.
Checkout the develop branch and create a new feature branch from there. Use a descriptive name and use dashes to separate words:
git checkout develop
git checkout -b add-megahit-assembly-step
Write or modify code in the scripts, rules and envs folders. Define the entry point of the workflow in the Snakefile and the main configuration in the config.yaml file.
If a new feature has been added, document it in the Sphinx documentation.
Commit changes to your fork/clone.
Create a pull request (PR) with some descriptions of the work you have done and possibly some explanations for potentially tricky bits.
When the feature is considered complete, we bump the version number and merge the PR back to the develop branch.
Releases
New releases are made whenever enough new features have accrued on the develop branch. Before creating a new release, ensure the following things have been taken care of:

All pending features that should be included in the upcoming release are merged into the develop branch.
Double check that documentation is up-to-date for implemented features.
Check that the version number in the documentation matches the Snakefile.
Then, merge the develop branch into master, squashing all commits, and tag the new release.

Code organization
The workflow code is organized in the following folder structure inside the git repository:

cluster_configs # Dir containing Snakemake profiles for clusters
docs # Sphinx documentation, only sources!
envs # Conda environment files
rules # The actual Snakemake rules that make up the workflow
scripts # Scripts used in workflow rules
utils # Auxiliary scripts, not used in workflow
config.yaml # The default config file
CONTRIBUTING.md # This document
LICENSE # LICENSE
README.md # The README shown in the github repo
Snakefile # The main workflow script
cluster_configs
The cluster_configs directory should contain either:

Folders representing entire Snakemake cluster profiles.
Single yaml or json cluster config files.
docs
The documentation for the project is built automatically by readthedocs upon every commit. The HTML documentation is available at https://stag-mwc.readthedocs.org. Feel free to improve the documentation, but avoid committing anything but source documents to the repo. The documentation is written using Sphinx, so all documentation sources are written in reStructuredText.