docs(project): adding project contributing guides (#99)

Signed-off-by: Pawan <pawan@mayadata.io>

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,32 @@
+---
+name: Bug report
+about: Tell us about a problem you are experiencing
+labels: Bug
+
+---
+
+**What steps did you take and what happened:**
+[A clear and concise description of what the bug is, and what commands you ran.]
+
+
+**What did you expect to happen:**
+
+
+**The output of the following commands will help us better understand what's going on**:
+(Pasting long output into a [GitHub gist](https://gist.github.com) or other [Pastebin](https://pastebin.com/) is fine.)
+
+* `kubectl logs -f openebs-zfs-controller-0 -n kube-system -c openebs-zfs-plugin`
+* `kubectl logs -f openebs-zfs-node-[xxxx] -n kube-system -c openebs-zfs-plugin`
+* `kubectl get pods -n kube-system`
+* `kubectl get zv -A -o yaml`
+
+**Anything else you would like to add:**
+[Miscellaneous information that will assist in solving the issue.]
+
+
+**Environment:**
+- ZFS-LocalPV version
+- Kubernetes version (use `kubectl version`):
+- Kubernetes installer & version:
+- Cloud provider or hardware configuration:
+- OS (e.g. from `/etc/os-release`):

.github/ISSUE_TEMPLATE/feature-request.md

@@ -0,0 +1,25 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+labels: Enhancement
+
+---
+
+**Describe the problem/challenge you have**
+[A description of the current limitation/problem/challenge that you are experiencing.]
+
+
+**Describe the solution you'd like**
+[A clear and concise description of what you want to happen.]
+
+
+**Anything else you would like to add:**
+[Miscellaneous information that will assist in solving the issue.]
+
+
+**Environment:**
+- ZFS-LocalPV version
+- Kubernetes version (use `kubectl version`):
+- Kubernetes installer & version:
+- Cloud provider or hardware configuration:
+- OS (e.g. from `/etc/os-release`):

.github/pull_request_template.md

@@ -0,0 +1,51 @@
+## Pull Request template
+
+Please, go through these steps before you submit a PR.
+
+**Why is this PR required? What issue does it fix?**:
+
+**What this PR does?**:
+
+**Does this PR require any upgrade changes?**:
+
+**If the changes in this PR are manually verified, list down the scenarios covered:**:
+
+**Any additional information for your reviewer?** :
+_Mention if this PR is part of any design or a continuation of previous PRs_
+
+
+**Checklist:**
+- [ ] Fixes #<issue number>
+- [ ] PR Title follows the convention of  `<type>(<scope>): <subject>`
+- [ ] Has the change log section been updated?
+- [ ] Commit has unit tests
+- [ ] Commit has integration tests
+- [ ] (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
+- [ ] (Optional) If documentation changes are required, which issue on https://github.com/openebs/openebs-docs is used to track them:
+
+
+**PLEASE REMOVE BELOW INFORMATION BEFORE SUBMITTING**
+
+The PR title message must follow convention:
+   `<type>(<scope>): <subject>`.
+
+Where: <br />
+- `type` is defining if release will be triggering after merging submitted changes, details in [CONTRIBUTING.md](../CONTRIBUTING.md).
+    Most common types are:
+    - `feat`      - for new features, not a new feature for build script
+    - `fix`       - for bug fixes or improvements, not a fix for build script
+    - `chore`     - changes not related to production code
+    - `docs`      - changes related to documentation
+    - `style`     - formatting, missing semi colons, linting fix etc; no significant production code changes
+    - `test`      - adding missing tests, refactoring tests; no production code change
+    - `refactor`  - refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes
+
+- `scope` is a single word that best describes where the changes fit.
+  Most common scopes are like:
+    - data engine (`localpv`, `jiva`, `cstor`)
+    - feature (`provisioning`, `backup`, `restore`, `exporter`)
+    - code component (`api`, `webhook`, `cast`, `upgrade`)
+    - test (`tests`, `bdd`)
+    - chores (`version`, `build`, `log`, `travis`)
+
+- `subject` is a single line brief description of the changes made in the pull request.

CONTRIBUTING.md

@@ -45,6 +45,13 @@ If you set your `user.name` and `user.email` in git config, you can sign your co
 
 You can also use git [aliases](https://git-scm.com/book/tr/v2/Git-Basics-Git-Aliases) like `git config --global alias.ci 'commit -s'`. Now you can commit with `git ci` and the commit will be signed.
 
+## Adding a changelog
+If PR is about adding a new feature or bug fix then the Author of the PR is expected to add a changelog file with their pull request. This changelog file should be a new file created under the `changelogs/unreleased` folder. Name of this file must be in `pr_number-username` format and contents of the file should be the one-liner text which explains the feature or bug fix.
+
+```sh
+zfs-localpv/changelogs/unreleased   <- folder
+    12-github_user_name            <- file
+```
 ## Setting up your Development Environment
 
 This project is implemented using Go and uses the standard golang tools for development and build. In addition, this project heavily relies on Docker and Kubernetes. It is expected that the contributors:

RELEASE.md

@@ -0,0 +1,39 @@
+# Release Process
+zfs-localpv follows a monthly release cadence. The scope of the release is determined by contributor availability. The scope is published in the [Release Tracker Projects](https://github.com/orgs/openebs/projects/10).
+
+## Release Candidate Verification Checklist
+
+Every release has release candidate builds that are created starting from the third week into the release. These release candidate builds help to freeze the scope and maintain the quality of the release. The release candidate builds will go through:
+- Platform Verification
+- Regression and Feature Verification Automated tests.
+- Exploratory testing by QA engineers
+- Strict security scanners on the container images
+- Upgrade from previous releases
+- Beta testing by users on issues that they are interested in.
+- Dogfooding on OpenEBS workload and e2e infrastructure clusters.
+
+If any issues are found during the above stages, they are fixed and a new release candidate builds are generated.
+
+Once all the above tests are completed, a main release tagged image is published.
+
+## Release Tagging
+
+zfs-localpv is released as container image with versioned tag.
+
+Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `master`. Name of the branch should follow the naming convention of `v.0.7.x` if release is for 0.7.0.
+
+Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder, if release branch is `v0.7.x` then folder will be `changelogs/v0.7.x`.
+
+The format of the release tag is either "Release-Name-RC1" or "Release-Name" depending on whether the tag is a release candidate or a release. (Example: 0.7.0-RC1 is a GitHub release tag for zfs-localpv release candidate build. 0.7.0 is the release tag that is created after the release criteria are satisfied by the zfs-localpv builds.)
+
+Once the release is triggered, Travis build process has to be monitored. Once Travis build passes, images are pushed to docker hub and quay.io. Images can be verified by going through docker hub and quay.io. Also, the images shouldn't have any high level vulnerabilities.
+
+Images are published at following location :
+
+https://quay.io/repository/openebs/zfs-driver?tab=tags
+https://hub.docker.com/r/openebs/zfs-driver/tags
+
+Once a release is created, update the release description with the changelog mentioned in `changelog/v0.7.x`. Once the changelogs are updated in the release, the repo owner needs to create a PR to `master` with the following details:
+1. update the changelog from `changelog/v0.7.x` to `zfs-localpv/CHANGELOG.md`
+2. If a release is not an RC tag then PR should include the changes to remove `changelog/v0.7.x` folder.
+3. If a release is an RC tag then PR should include the changes to remove the changelog from `changelog/v0.7.x` which are already mentioned in `zfs-localpv/CHANGELOG.md` as part of step number 1.