CONTRIBUTING.md

Contributing Guidelines

Replicated PV Mayastor

Umbrella Project

OpenEBS is an umbrella project ☂️, where every project, repository and file in the OpenEBS organization adopts and follows the policies and principles of the umbrella project files located in our Community repo cafe.

The Replicated PV Mayastor Storage Engine project adheres to the: OpenEBS Contributor Guidelines

---

Quick links	CNCF openebs website	CNCF Product docs	Main Parent repo	Community Cafe

Important

Contributing to MayaStor

We're excited that you are interested in contributing to the Replicated PV MayaStor Storage Engine.
If you experience minor hurdles in contribution, please report them.

	Try our Slack channel If you have questions about using OpenEBS, please use the CNCF Kubernetes OpenEBS slack channel, it is open for anyone to ask a question

Our interactions here are governed by the openEBS Code of Conduct.

Development Environment

Consult the doc/build.md for a complete guide on who to get started contributing to the Replicated PV MayaStor Storage Engine.

---

Issues & Pull Requests

Reporting Bugs

Please try to report complete, well described, reproducible bugs to us. If you can't, that's ok. Do your best.

• Our [Bug Report][issue-bug-report] template includes instructions on providing the information we need from you.

Requesting new features

You are invited to propose complete, well described new features via...

• For a MAJOR NEW FEATURE, submit an OEP (openEBS Enhancement Proposal). Maintainers will review & discuss the new feature proposal and potentially schedule community discussions on it. The OEP process is new for us, so please bear with us on this.
• or submit a detailed ISSUE in the community Cafe Repo
  • You must indicate if you are able to complete and support the features you propose.
• Note: Raising PR's as a Feature Request is not the process for requesting new features. Such PR's will be closed, and you will asked to resubmit as an OEP or an ISSUE.
  • All PR's are reviewed by the Maintainers and Eng/Dev first, before being approved and committed for Eng/development.

The processes above are documented in the community Cafe repo discussion tab. If you can’t find them, please reach out one of the Maintainers below. We're happy to help.

Coding language & style

While the Replicated PV MayaStor Storage Engine has no formal RFC process, the [Rust RFC template][rust-rfc-template] is an excellent place to derive your issue description from.

	🦀 The Replicated PV MayaStor Storage Engine is 100% developed in the RUST programming language 🦀 We leverage guidance from the RUST community. 🦀 We love Ferris. 🦀 We are #rustaceans

---

Committing

You must start you Development work off the develop branch. Do Not use master. - (We do not use that branch name.)

⭐ We run the [bors][bors] PR Merge bot tool. ⭐ Bors will merge your commits once they has passed review. ⭐ Please ask if you need to [squash merges][squash-merges]. We generally do this. It's best to ask first. ⭐ Each commit message must adhere to [Conventional Commits][conventional-commits]. ⭐ You can use [convco][tools-convco] if you need a tool to help with commit msgs. ⭐ It O.K to force push your branch if you need. Feel free to rewrite commit history it needed.

---

Reviews

⚡ The review process is governed by [bors][bors]. ⚡ Pull requests require at least 2 approvals from Maintainers or SIG members. ⚡ Once review is given, Maintainers and SIG members may indicate merge readiness. ⚡ The comment message bors merge will auto trigger a merge.   ⚠️ Do not hit the 'Update Branch' button.   ⚠️ The commit message is not conventional, [bors][bors] will yell at you.   ⚠️ Let [bors][bors] handle it, or rebase it yourself.

---

	Try our Slack channel If you have questions about using OpenEBS, please use the CNCF Kubernetes OpenEBS slack channel, it is open for anyone to ask a question

---

Project Leadership team

This Community is managed by the OpenEBS Admins, Maintainers and Senior leaders within the OpenEBS project team. We liaise with the Linux Foundation and CNCF on project, governance and operational matters. We curate the daily operations of the project, product, roadmaps, initiatives, all engineering/code activities and all events (including conferences). Currently our leadership team is...

Name	GitHub	Geo	Role	Lead
Vishnu Attur	@avishnu		Admin, Maintainer	Eng/QA / PRs / Issues
Abhinandan Purkait	😎 @Abhinandan-Purkait		Maintainer	PR's / Issues
Niladri Halder	🚀 @niladrih		Maintainer	PR's / Issues
Ed Robinson	🐶 @edrob999		CNCF Primary Liason	CNCF / Biz
Tiago Castro	⚡ @tiagolobocastro		Admin, Maintainer	PR's / Issues / Arch
David Brace	⭐ @orville-wright		Admin, Maintainer	Prod / Issues / Biz

Important

When creating an ISSUE or a PR. Please TAG one (or more) of the Maintainers.

Our Special Interest Groups (SIGs) are:

Functional area	Name	@GitHub	Area of Expertise	Product specialization
Entire Product	Tiago Castro	@tiagolobocastro	Architect / Eng	Mayastor
Data Plane	Dmitry Savitskiy	@dsavitskiy	Architect / Eng	Mayastor
e2e Testing	Blaise Dias	@blaisedias	Eng / Test / QA	All products
e2e Testing	Chris Denyer	@chriswldenyer	Eng / QA	Mayastor

---

Important

FAQ's on SIG's, Contributors and Maintainers

What is a Special Interest Group (SIG)?

• SIGs are small teams working together on a specific area/topic/zone.
• They may change at any time, and have no strict definition.
• SIGs may be created, empowered, and destroyed by the maintainers at any time.

May I join a SIG?

• Of course, we'd love that!

May I Become a maintainer?

• Yes, we have a set of guidelines and rules explaining how to advance to Maintainer-ship...
  • Governance rules, code of conduct, contributing and a Maintainer Ladder that details pre-reqs, criteria and responsibilities you need to agree to & meet
  • Contribution history is critical
  • PR review input, ISSUE management
  • Attendance at community meetings are also important
  • Feature contribution
  • Active support engagement on our SLACK Channel
  • Bug resolution