Adding following files for the project:

  - issue template
  - feature request template
  - CODE_OF_CONDUCT.md
  - CONTRIBUTING.md
  - GOVERNANCE.md
  - MAINTAINERS
  - README.md
  - code-standard.md
  - developer-setup.md

Signed-off-by: mayank <[email protected]>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,38 @@
+---
+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 deployment/velero -n velero`
+* `kubectl logs deployment/maya-apiserver -n openebs`
+* `velero backup describe <backupname>` or `kubectl get backup/<backupname> -n velero -o yaml`
+* `velero backup logs <backupname>`
+* `velero restore describe <restorename>` or `kubectl get restore/<restorename> -n velero -o yaml`
+* `velero restore logs <restorename>`
+
+
+**Anything else you would like to add:**
+[Miscellaneous information that will assist in solving the issue.]
+
+
+**Environment:**
+- Velero version (use `velero version`):
+- Velero features (use `velero client config get features`):
+- Velero-plugin 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,28 @@
+---
+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:**
+- Velero version (use `velero version`):
+- Velero features (use `velero client config get features`):
+- Velero-plugin version
+- 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,16 @@
+## 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>`.
+    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,46 @@
+# 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, gender identity and expression, level of experience, 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]. The project team will review and investigate all complaints, and will respond in a way that it deems 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 [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,122 @@
+# Contributing to velero-plugin
+
+velero-plugin is an open-source project.
+
+velero-plugin uses the standard GitHub pull requests process to review and accept contributions.
+
+You can contribute to velero-plugin by filling an issue at [openebs/velero-plugin](https://github.com/openebs/velero-plugin/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/velero-plugin/issues).
+
+### Filing issue
+
+When filing an issue, make sure to answer these seven questions:
+
+1. What version of Velero are you using (`velero version`)?
+2. What version of OpenEBS are you using?
+3. What version of velero-plugin are you using?
+4. What steps did you follow to create a backup or restore?
+5. What did you expect to see?
+6. What did you see instead?
+7. Logs of velero/velero pod and openebs/maya-apiserver pod.
+
+#### 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
+velero-plugin 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](developer-setup.md).
+
+* Find an issue to work on or create a new issue. The issues are maintained at [openebs/velero-plugin](https://github.com/openebs/velero-plugin/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/velero-plugin/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](code-standard.md).
+* Verify that your changes pass `make lint` or `make lint-docker` (docker version of `make lint`)
+* 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(backup): support for backup to aws
+   ^--^ ^-----^   ^-----------------------^
+     |     |         |
+     |     |         +-> 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/velero-plugin/issues) then you need to mention the issue number with a link in PR description. like: _fixes https://github.com/openebs/velero-plugin/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.**

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).
+

MAINTAINERS

@@ -0,0 +1,16 @@
+# 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
+"Mayank Patel",@mynktl,MayaData
+"Vishnu Itta",@vishnuitta,MayaData
+
+#Reviewers
+"Kiran Mova",@kmova,MayaData
+"Mayank Patel",@mynktl,MayaData
+"Vishnu Itta",@vishnuitta,MayaData

README.md

@@ -6,8 +6,10 @@ To do backup/restore of OpenEBS CStor volumes through Velero utility, you need t
 OpenEBS velero-plugin.
 
 [![Build Status](https://travis-ci.org/openebs/velero-plugin.svg?branch=master)](https://travis-ci.org/openebs/velero-plugin)
+[![Slack](https://img.shields.io/badge/chat!!!-slack-ff1493.svg?style=flat-square)](https://kubernetes.slack.com/messages/openebs)
 [![Go Report](https://goreportcard.com/badge/github.com/openebs/velero-plugin)](https://goreportcard.com/report/github.com/openebs/velero-plugin)
 [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fopenebs%2Fvelero-plugin.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fopenebs%2Fvelero-plugin?ref=badge_shield)
+[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3900/badge)](https://bestpractices.coreinfrastructure.org/projects/3900)
 
 ## Table of Contents
 - [Compatibility matrix](#compatibility-matrix)

RELEASE.md

@@ -0,0 +1,38 @@
+# Release Process
+velero-plugin 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/openebs/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
+
+velero-plugin 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 velero-plugin release build. v1.9.0 is the release tag that is created after the release criteria are satisfied by the velero-plugin 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/velero-plugin?tab=tags
+https://hub.docker.com/r/openebs/velero-plugin/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 `velero-plugin/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 `velero-plugin/CHANGELOG.md` as part of step number 1.