docs(contributor): adding project contribution guidelines (#22)

Signed-off-by: Utkarsh Mani Tripathi <[email protected]>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,32 @@
+---
+name: Bug report
+about: Tell us about a problem you are experiencing
+
+---
+
+**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 is fine.)
+
+* `kubectl logs <jiva-csi controller pod name> -n kube-system`
+* `kubectl logs <jiva-csi node pod name> -n kube-system`
+* `kubectl get jv <jiva volume cr name> -n openebs`
+* `kubectl get jvp <jiva volume policy name> -n openebs`
+
+**Anything else you would like to add:**
+[Miscellaneous information that will assist in solving the issue.]
+
+
+**Environment:**
+- Jiva version
+- OpenEBS 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,24 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+
+---
+
+**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:**
+- OpenEBS 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,17 @@
+## Pull Request template
+Please, go through these steps before you submit a PR.
+
+1. This repository follows semantic versioning convention, therefore each PR title/commit message must follow convention: `<type>(<scope>): <subject>`.
+   `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
+
+IMPORTANT: Please review the [CONTRIBUTING.md](../CONTRIBUTING.md) file for detailed contributing guidelines.
+
+**PLEASE REMOVE THIS TEMPLATE BEFORE SUBMITTING**

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,93 @@
+# Contributing to OpenEBS jiva-csi
+
+OpenEBS uses the standard GitHub pull requests process to review and accept contributions.  There are several areas that could use your help. For starters, you could help in improving the sections in this document by either creating a new issue describing the improvement or submitting a pull request to this repository. The issues for the various OpenEBS components (including jiva-csi components) are maintained in [openebs/openebs](https://github.com/openebs/openebs/issues) repository.
+
+* If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute).
+* If you have documentation improvement ideas, go ahead and create a pull request. See [Pull Request checklist](#pull-request-checklist).
+* If you would like to make code contributions, please start with [Setting up the Development Environment](#setting-up-your-development-environment).
+* If you would like to work on something more involved, please connect with the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community).
+
+## Steps to Contribute
+
+OpenEBS is an Apache 2.0 Licensed project and all your commits should be signed with Developer Certificate of Origin. See [Sign your work](#sign-your-work).
+
+* Find an issue to work on or create a new issue. The issues are maintained at [openebs/openebs](https://github.com/openebs/openebs/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/openebs/labels/good%20first%20issue).
+* Claim your issue by commenting your intent to work on it to avoid duplication of efforts.
+* Fork the repository on GitHub.
+* Create a branch from where you want to base your work (usually master).
+* Make your changes. If you are working on code contributions, please see [Setting up the Development Environment](#setting-up-your-development-environment).
+* Relevant coding style guidelines are the [Go Code Review Comments](https://code.google.com/p/go-wiki/wiki/CodeReviewComments) and the _Formatting and style_ section of Peter Bourgon's [Go: Best Practices for Production Environments](http://peter.bourgon.org/go-in-production/#formatting-and-style).
+* Commit your changes by making sure the commit messages convey the need and notes about the commit.
+* Push your changes to the branch in your fork of the repository.
+* Submit a pull request to the original repository. See [Pull Request checklist](#pull-request-checklist).
+
+## Pull Request Checklist
+
+* Rebase to the current master branch before submitting your pull request.
+* Commits should be as small as possible. Each commit should follow the checklist below:
+  - For code changes, add tests relevant to the fixed bug or new feature.
+  - Pass the compile and tests - includes spell checks, formatting, etc.
+  - Commit header (first line) should convey what changed.
+  - Commit body should include details such as why the changes are required and how the proposed changes.
+  - DCO Signed.
+* If your PR is not getting reviewed or you need a specific person to review it, please reach out to the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community).
+
+## Sign your work
+
+We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS project. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please read [dcofile](https://github.com/openebs/openebs/blob/master/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message:
+
+````
+  Signed-off-by: Random J Developer <[email protected]>
+````
+
+Use your real name (sorry, no pseudonyms or anonymous contributions). The email id should match the email id provided in your GitHub profile.
+If you set your `user.name` and `user.email` in git config, you can sign your commit automatically with `git commit -s`.
+
+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.
+
+## 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:
+-   are familiar with working with Go;
+-   are familiar with Docker containers;
+-   are familiar with Kubernetes and have access to a Kubernetes cluster or Minikube to test the changes.
+
+### Prerequisites
+
+-   You have Go 1.10+ installed on your local host/development machine.
+-   Requires *curl* and *docker* to be installed on your build machine. 
+
+### Fork in the cloud
+
+1. Visit https://github.com/openebs/jiva-csi.
+2. Click `Fork` button (top right) to establish a cloud-based fork.
+
+### Clone fork to local host
+
+Place openebs/jiva-csi' code on your `GOPATH` using the following cloning procedure.
+Create your clone:
+
+```
+mkdir -p $GOPATH/src/github.com/openebs
+cd $GOPATH/src/github.com/openebs
+
+# Note: Here $user is your GitHub profile name
+git clone https://github.com/$user/jiva-csi.git
+
+# Configure remote upstream
+cd $GOPATH/src/github.com/openebs/jiva-csi
+git remote add upstream https://github.com/openebs/jiva-csi.git
+
+# Never push to upstream master
+git remote set-url --push upstream no_push
+
+# Confirm that your remotes make sense
+git remote -v
+```
+
+### Make your changes and build them
+
+ ```
+ cd $GOPATH/src/github.com/openebs/jiva-csi
+ make build
+ ```

GOVERNANCE.md

@@ -0,0 +1,2 @@
+This is a OpenEBS sub project and abides by the 
+[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md).

MAINTAINERS

@@ -0,0 +1,13 @@
+# Official list of OpenEBS Maintainers.
+#
+# Names added to this file should be in the following format:
+#     Individual's name,@githubhandle, Company Name
+#
+# Please keep the below list sorted in ascending order.
+#
+#Maintainers
+"Kiran Mova",@kmova,MayaData
+
+#Reviewers
+"Utkarsh Mani Tripathi",@utkarshmani1997,MayaData
+"Shubham Bajpai", @shubham14bajpai,MayaData

RELEASE.md

@@ -0,0 +1,38 @@
+# Release Process
+jiva-operator 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).
+
+## 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
+
+jiva-operator is released as container image with versioned tag.
+
+Before creating a release, 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.1.9.x`, if release is for 1.9.0.
+
+Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder `changelogs/v1.9.x`, if release branch is `v1.10.x` then folder will be `changelogs/v1.10.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: 1.9.0-RC1 is a GitHub release tag for jiva-operator release build. 1.9.0 is the release tag that is created after the release criteria are satisfied by the jiva-operator builds.)
+
+Once the release is triggered, Travis build process has to be monitored. Once Travis build is passed 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/jiva-operator?tab=tags
+https://hub.docker.com/r/openebs/jiva-operator/tags
+
+Once a release is created, update the release description with the change log mentioned in `changelog/v1.9.x`. Once the change logs are updated in release, repo owner needs to create a PR to `master` with the following details:
+1. update the changelog from `changelog/v1.9.x` to `jiva-operator/CHANGELOG.md`
+2. If release is not a RC tag then PR should include the changes to remove `changelog/v1.9.x` folder.
+3. If release is a RC tag then PR should include the changes to remove the changelog from `changelog/v1.9.x` which are already mentioned in `jiva-operator/CHANGELOG.md` as part of step number 1.

code-standard.md

@@ -0,0 +1,26 @@
+# Code Standards
+
+## Sign your commits
+
+We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS projects. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please read [dcofile](https://github.com/openebs/openebs/blob/master/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message:
+
+````
+  Signed-off-by: Random J Developer <[email protected]>
+````
+
+Use your real name (sorry, no pseudonyms or anonymous contributions). The email id should match the email id provided in your GitHub profile.
+If you set your `user.name` and `user.email` in git config, you can sign your commit automatically with `git commit -s`.
+
+## Verifying code style
+
+```
+make vet
+```
+
+## Adding a changelog
+If PR is about adding a new feature or bug fixes then Authors of the PR are expected to add a changelog file with their pull request. This changelog file should be a new file created under `changelogs/unreleased` folder. Name of this file must be in in `pr_number-username` format and contents of the file should be the one liner text which explain the feature or bug fix.
+
+```sh
+jiva-csi/changelogs/unreleased   <- folder
+    12-github_user_name      <- file
+```