-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Abhinandan Purkait <[email protected]>
- Loading branch information
1 parent
9d97703
commit c9415ea
Showing
5 changed files
with
22 additions
and
219 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,46 +1,8 @@ | ||
| # Contributor Covenant Code of Conduct | ||
| # Code of Conduct | ||
| <BR> | ||
|
|
||
| ## Our Pledge | ||
| ## Umbrella Project | ||
| OpenEBS is an "umbrella project". Every project, repository and file in the OpenEBS organization adopts and follows the policies found in the Community repo umbrella project files. | ||
| <BR> | ||
|
|
||
| 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/ | ||
| This project follows the [OpenEBS Code of Conduct](https://github.com/openebs/community/CODE_OF_CONDUCT.md) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,148 +1,9 @@ | ||
| # Contributing to openebsctl | ||
| # Contributing Guidelines | ||
| <BR> | ||
|
|
||
| openebsctl 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 are maintained at [openebs/openebs](https://github.com/openebs/openebs/issues?q=is%3Aissue+is%3Aopen+label%3Aopenebsctl) repository. | ||
| ## Umbrella Project | ||
| OpenEBS is an "umbrella project". Every project, repository and file in the OpenEBS organization adopts and follows the policies found in the Community repo umbrella project files. | ||
| <BR> | ||
|
|
||
| * If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute). | ||
| * If you want to file an issue for a bug or feature request, please see [Filing a issue](#filing-an-issue) | ||
| * 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) | ||
| This project follows the [OpenEBS Contributor Guidelines](https://github.com/openebs/community/CONTRIBUTING.md) | ||
|
|
||
| ## Steps to Contribute | ||
|
|
||
| openebsctl 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?q=is%3Aissue+is%3Aopen+label%3Aopenebsctl). You can pick up from a list of [good-first-issues](https://github.com/openebs/openebsctl/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. The commit message format followed for OpenEBS projects can be found [here](https://github.com/openebs/openebs/blob/master/contribute/git-commit-message.md). | ||
| * 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) | ||
|
|
||
| ## 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/openebs/issues). | ||
|
|
||
| ### Filing issues | ||
|
|
||
| When filing an issue, make sure to answer these seven questions: | ||
|
|
||
| 1. What version of OpenEBS are you using? | ||
| 2. What did you expect to see? | ||
| 3. What did you see instead? | ||
|
|
||
| #### For maintainers | ||
| * We are using labelling for issue to track it more effectively. Following are valid labels for the issue. | ||
| - **Bug** - if issue is a **bug to existing feature** | ||
| - **Enhancement** - if issue is a **feature request** | ||
| - **Maintenance** - if issue is not related to production code. **build, document or test related issues falls into this category** | ||
| - **Question** - if issue is about **querying information about how product or build works, or internals of product**. | ||
| - **Documentation** - if issue is about **tracking the documentation work for the feature**. This label should not be applied to the issue about bug in documentations. | ||
| - **Good First Issue** - if issues is easy to get started with. Please make sure that issue should be ideal for beginners to dive into the code base. | ||
| - **Duplicate** - if issue is **duplicate of another issue** | ||
| - **Help Wanted** - if issue **requires extra attention** from more users/contributors | ||
|
|
||
| * We are using following labels for issue work-flow: | ||
| - **Backlog** - if issues has **not been planned for current release cycle** | ||
| - **Release-Note/Closed** - if issue is still open / being worked in a release | ||
| - **Release-Note/Open** - if issue has been **resolved in a release** | ||
| - **Wont Fix** - if the issue will not be worked on | ||
|
|
||
| **If you want to introduce a new label then you need to raise a PR to update this document with the new label details.** | ||
|
|
||
| ## 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 compilation 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 help | ||
| - DCO Signed, please refer [signing commit](code-standard.md/sign-your-commits) | ||
| * If your PR is about fixing a 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(partition) : add support for partitions | ||
| ^--^ ^-----^ ^-----------------------^ | ||
| | | | | ||
| | | +-> 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 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 | ||
| * `cherry-pick` - if PR is merged in master branch and raised to release branch | ||
|
|
||
| * 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 contributors have confirmed their right to license their contribution under the project's license. Please read [developer-certificate-of-origin](./contribute/developer-certificate-of-origin). | ||
|
|
||
| Please certify it by just adding a line to every git commit message. Any PR with Commits which does not have DCO Signoff will not be accepted: | ||
|
|
||
| ``` | ||
| Signed-off-by: Random J Developer <[email protected]> | ||
| ``` | ||
|
|
||
| or use the command `git commit -s -m "commit message comes here"` to sign-off on your commits. | ||
|
|
||
| Use your real name (sorry, no pseudonyms or anonymous contributions). If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. You can also use git [aliases](https://git-scm.com/book/en/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. | ||
|
|
||
| --- | ||
|
|
||
| ## 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](https://github.com/openebs/openebs/issues) then you need to mention the issue number with link in PR description. like : _fixes https://github.com/openebs/openebs/issues/2961_ | ||
|
|
||
| * If PR is for bug-fix and release branch(like v0.4.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 fix after RC release are cherry-picked to release branch. | ||
|
|
||
| ### For maintainers | ||
| * We are using labelling for PR to track it more effectively. 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 following label for PR work-flow: | ||
| - **pr/hold-review** - if PR is currently being developed, and is not yet ready for review | ||
| - **pr/hold-merge** - if PR is waiting on some dependencies, and should not be merged even if approved | ||
| - **pr/documentation-pending** - if the changes in PR are yet to be documented | ||
| - **pr/documentation-complete** - if the changes / features in the PR are already included in the documentation | ||
| - **pr/release-note-alpha** - the changes in this PR should be included in the alpha feature list in release note | ||
| - **pr/release-note** - the changes in this PR should be included in the release note | ||
| - **pr/upgrade-automated** - upgrade is automated for changes in this PR | ||
| - **pr/upgrade-pending** - the automatic upgrade for the changes in this PR are yet to be done. | ||
|
|
||
| * 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.** | ||
|
|
||
| ## 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 or Local K8s cluster to test the changes. | ||
|
|
||
| For setting up a Development environment on your local host, see the detailed instructions [here](./BUILD.md). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,2 +1,8 @@ | ||
| This is a OpenEBS sub project and abides by the | ||
| [OpenEBS Project Governance](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md). | ||
| # Governance | ||
| <BR> | ||
|
|
||
| ## Umbrella Project | ||
| OpenEBS is an "umbrella project". Every project, repository and file in the OpenEBS organization adopts and follows the policies found in the Community repo umbrella project files. | ||
| <BR> | ||
|
|
||
| This project follows the [OpenEBS Governance](https://github.com/openebs/community/GOVERNANCE.md) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,26 +1 @@ | ||
| # Official list of OpenEBS Maintainers. | ||
| # | ||
| # Names added to this file should be in the following format: | ||
| # Individual's name,@githubhandle, Company Name | ||
| # | ||
| # Each of the OpenEBS sub project may have one or more of the | ||
| # following maintainers and list of reviewers who are | ||
| # in the process of becoming maintainers. | ||
| # | ||
| # | ||
| # Each reviewer can be part of one or more GitHub | ||
| # team aliases created for maintaining sub projects. | ||
| # Current active team aliases for sub projects are: | ||
| # - control-plane-maintainers | ||
| # | ||
| # Please keep the below list sorted in ascending order. | ||
| # | ||
| #Maintainers | ||
| "Kiran Mova",@kmova,MayaData | ||
| "Vishnu Itta",@vishnuitta,MayaData | ||
|
|
||
| #Reviewers | ||
| "Prateek Pandey",@prateekpandey14,MayaData #control-plane-maintainers | ||
| "Ashutosh Kumar",@sonasingh46,MayaData #control-plane-maintainers | ||
| "Sai Chaithanya",@mittachaitu,MayaData #control-plane-maintainers | ||
| "Vani Singh",@vaniisgh | ||
| See [OpenEBS Maintainers](https://github.com/openebs/community/MAINTAINERS.md) |