docs(project): add project contributor specific files and github templates (#78)

prateekpandey14 · web-flow · commit dceb0a668862 · 2020-05-02T22:33:17.000+05:30
Signed-off-by: prateekpandey14 &lt;prateek.pandey@mayadata.io&gt;
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,37 @@
+---
+name: Bug Report
+about: Report a bug encountered while operating on cstor-csi volumes
+labels: kind/bug
+
+---
+
+<!-- Please use this template while reporting a bug and provide as much info as possible.
+     Not doing so may result in your bug not being addressed in a timely manner. Thanks!
+-->
+
+**Describe the bug:** A clear and concise description of what the bug is.
+
+**Expected behaviour:** A concise description of what you expected to happen
+
+**Steps to reproduce the bug:**
+Steps to reproduce the bug should be clear and easily reproducible to help people gain an understanding of the problem
+
+**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 get cstorvolume <pv-name> -n <openebs_namespace> -o yaml`
+* `kubectl get cstorvolumeconfig <pv-name> -n <openebs_namespace> -o yaml`
+* `kubectl logs sts/openebs-cstor-csi-controller -n kube-system -c openebs-csi-plugin`
+* `kubectl logs ds/openebs-cstor-csi-node -n kube-system -c openebs-csi-plugin`
+* `kubectl get pods -n <openebs_namespace>`
+
+**Anything else we need to know?:**
+Add any other context about the problem here.
+
+**Environment details:**
+- OpenEBS version (use `kubectl get po -n openebs --show-labels`):
+- Kubernetes version (use `kubectl version`):
+- Cloud provider or hardware configuration:
+- OS (e.g: `cat /etc/os-release`):
+- kernel (e.g: `uname -a`):
+- others:
diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md
@@ -0,0 +1,26 @@
+---
+name: Feature request
+about: Suggest an idea to improve cstor-csi driver
+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:**
+- OpenEBS version (use `kubectl get po -n openebs --show-labels`):
+- Kubernetes version (use `kubectl version`):
+- Cloud provider or hardware configuration:
+- OS (e.g: `cat /etc/os-release`):
+- kernel (e.g: `uname -a`):
+- others:
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
@@ -0,0 +1,21 @@
+<!--  Thanks for sending a pull request!  Before submitting:
+
+1. Read our CONTRIBUTING.md guide for detailed contributing guidelines.
+2. Rebase your PR if it gets out of sync with master
+-->
+
+**What this PR does**:
+
+**Which issue(s) this PR fixes**:
+Fixes #<issue number>
+
+
+**Special notes for your reviewer**:
+
+**Checklist**
+- [ ] PR messages has document related information
+- [ ] Labelled this PR & related issue with `documentation` tag
+- [ ] PR messages has breaking changes related information
+- [ ] PR messages has upgrade related information
+- [ ] Labelled this PR & related issue with `requires-upgrade` tag
+- [ ] Tests updated
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
@@ -0,0 +1,3 @@
+## Community Code of Conduct
+
+This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -0,0 +1,118 @@
+# Contributing to CStor-csi driver
+
+CStor-csi driver is an open-source project, and follows the standard GitHub pull requests process to review and accept contributions.
+
+You can contribute to cstor-csi driver by filling an issue at [openebs/cstor-csi](https://github.com/openebs/cstor-csi/issues) or submitting a pull request to this repository.
+
+* If you want to file an issue for bug or feature request, please see [Filing an issue](#filing-an-issue)
+* If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute) and code standard(code-standard.md).
+* 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)
+
+## Filing an issue
+### Before filing an issue
+
+If you are unsure whether you have found a bug, please consider asking in the [Slack](https://kubernetes.slack.com/messages/openebs) first. If
+the behavior you are seeing is confirmed as a bug or issue, it can easily be re-raised in the [issue tracker](https://github.com/openebs/cstor-csi/issues).
+
+### Filing issue
+
+When filing an issue, make sure to answer these seven questions:
+
+1. What version of cstor-csi are you using?
+2. What version of OpenEBS are you using?
+5. What did you expect to see?
+6. What did you see instead?
+7. Logs of `csi-controller/openebs-csi-plugin` pod in kube-system namespace and `cvc-operator` pod in openebs namespace.
+
+#### For maintainers
+* We are using labeling for the issue to track it more effectively. The following are valid labels for the issue.
+   - **Bug** - If the issue is a **bug to existing feature**
+   - **Enhancement** - If the issue is a **feature request**
+   - **Maintenance**  - If the issue is not related to production code. **build, document or test related issues fall into this category**
+   - **Question** - If the issue is about **querying information about how the product or build works, or internal of product**.
+   - **Documentation** - If the issue is about **tracking the documentation work for the feature**. This label should not be applied to the issue of a bug in documentations.
+   - **Good First Issue** - If the issue is easy to get started with. Please make sure that the issue should be ideal for beginners to dive into the codebase.
+   - **Design** - If the issue **needs a design decision prior to code implementation**
+   - **Duplicate** - If the issue is **duplicate of another issue**
+
+* We are using following labels for issue work-flow:
+   - **Backlog** - If the issue has **not been planned for current release cycle**
+   - **Release blocker** - If the issue is **blocking the release**
+   - **Priority: high** - issue with this label **should be resolved as quickly as possible**
+   - **Priority: low** - issue with this label **won’t have the immediate focus of the core team**
+
+**If you want to introduce a new label then you need to raise a PR to update this document with the new label details.**
+
+## Steps to Contribute
+CStor-csi 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).
+
+For setting up a development environment on your local machine, see the detailed instructions [here](docs/developer-setup.md).
+
+* Find an issue to work on or create a new issue. The issues are maintained at [openebs/cstor-csi](https://github.com/openebs/cstor-csi/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/cstor-csi/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).
+* Commit your changes by making sure the commit messages convey the need and notes about the commit.
+* Please make sure than your code is aligned with the standard mentioned at [code-standard](docs/code-standard.md).
+* Verify that your changes pass `make lint` and `make test`
+* 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.
+  - 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 help
+  - DCO Signed, please refer [signing commit](code-standard.md/sign-your-commits)
+* If your PR is about fixing an issue or new feature, make sure you add a change-log. Refer [Adding a Change log](code-standard.md/adding-a-changelog)
+* PR title must follow convention: `<type>(<scope>): <subject>`.
+
+  For example:
+  ```
+   feat(metrics): support for raw block device metrics
+   ^--^ ^-----^   ^-----------------------^
+     |     |         |
+     |     |         +-> PR subject, summary of the changes
+     |     |
+     |     +-> scope of the PR, i.e. component of the project this PR is intend to update
+     |
+     +-> type of the PR.
+  ```
+
+    Most common types are:
+    * `feat`        - for new features, not a new feature for the build script
+    * `fix`         - for bug fixes or improvements, not a fix for the build script
+    * `chore`       - changes not related to production code
+    * `docs`        - changes related to documentation
+    * `style`       - formatting, missing semicolons, 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
+    * `cherry-pick` - if PR is merged in the master branch and raised to release branch(like v1.9.x)
+
+## Code Reviews
+All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult [GitHub Help](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) for more information on using pull requests.
+
+* 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)
+
+* If PR is fixing any issues from [github-issues](github.com/openebs/cstor-csi/issues) then you need to mention the issue number with a link in PR description. like: _fixes https://github.com/openebs/cstor-csi/issues/56_
+
+* If PR is for bug-fix and release branch(like v1.9.x) is created then cherry-pick for the same PR needs to be created against the release branch. Maintainer of the Project needs to make sure that all the bug fixes after RC release are cherry-picked to release branch.
+
+### For maintainers
+* We are using labeling for PR to track it more effectively. The following are valid labels for the PR.
+   - **Bug** - if PR is a **bug to existing feature**
+   - **Enhancement** - if PR is a **feature request**
+   - **Maintenance**  - if PR is not related to production code. **build, document or test related PR falls into this category**
+   - **Documentation** - if PR is about **tracking the documentation work for the feature**. This label should not be applied to the PR fixing bug in documentations.
+
+* We are using the following label for PR work-flow:
+   - **DO NOT MERGE** - if PR is about critical changes and no scope of testing before release branch creation
+   - **On Hold** - if PR doesn't have sufficient changes, all the scenarios are not covered or changes are requested from contributor
+   - **Release blocker** - if PR is created for the issue having label **Release blocker**
+   - **Priority: high** - if PR is created for the issue having label **Priority: high**
+   - **Priority: low** - if PR is created for the issue having label **Priority: low**
+
+* Maintainer needs to make sure that appropriate milestone and project tracker is assigned to the PR.
+
+**If you want to introduce a new label then you need to raise a PR to update this document with the new label details.**
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
@@ -0,0 +1,3 @@
+This is a OpenEBS sub project and abides by the
+[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md).
+
diff --git a/MAINTAINERS b/MAINTAINERS
@@ -0,0 +1,19 @@
+# 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
+"Payes Anand",@payes,MayaData
+"Prateek Pandey",@prateekpandey14,MayaData
+"Vishnu Itta",@vishnuitta,MayaData
+
+#Reviewers
+"Kiran Mova",@kmova,MayaData
+"Payes Anand",@payes,MayaData
+"Prateek Pandey",@prateekpandey14,MayaData
+"Utkarsh Mani Tripathi",@utkarshmani1997,MayaData
+"Vishnu Itta",@vishnuitta,MayaData
diff --git a/RELEASE.md b/RELEASE.md
@@ -0,0 +1,38 @@
+# Release Process
+CStor-csi 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
+
+CStor-csi is released as a container image with a 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.1.9.x` if the release is for v1.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: v1.9.0-RC1 is a GitHub release tag for the cstor-csi release build. v1.9.0 is the release tag that is created after the release criteria are satisfied by the cstor-csi 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 the following location:
+https://quay.io/repository/openebs/cstor-csi?tab=tags
+https://hub.docker.com/r/openebs/cstor-csi/tags
+
+Once a release is created, update the release description with the changelog mentioned in `changelog/v1.9.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/v1.9.x` to `cstor-csi/CHANGELOG.md`
+2. If a release is not an RC tag then PR should include the changes to remove `changelog/v1.9.x` folder.
+3. If a release is an RC tag then PR should include the changes to remove the changelog from `changelog/v1.9.x` which are already mentioned in `cstor-csi/CHANGELOG.md` as part of step number 1.
diff --git a/docs/code-standard.md b/docs/code-standard.md
@@ -0,0 +1,24 @@
+# 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 <random@developer.example.org>
+````
+
+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
+
+We are using [golangci-lint](https://github.com/golangci/golangci-lint) to verify the linting errors. Make sure that your changes pass linting check by executing `make lint`.
+
+## 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
+cstor-csi/changelogs/unreleased   <- folder
+    14-github_user_name            <- file
+```
diff --git a/docs/developer-setup.md b/docs/developer-setup.md

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+## Community Code of Conduct`
	`2`	`+`
	`3`	`+This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+This is a OpenEBS sub project and abides by the`
	`2`	`+[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md).`
	`3`	`+`