Add CONTRIBUTING.md, GOVERNANCE.md, MAINTAINERS.md Docs

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @kanisterio/maintainers

CONTRIBUTING.md

@@ -0,0 +1,125 @@
+# Contributing to Kanister
+
+Welcome, and thank you for considering contributing to Kanister. We welcome all
+help in raising issues, improving documentation, fixing bugs, or adding new
+features.
+
+If you are interested in contributing, start by reading this document. Please
+also take a look at our [code of conduct](CODE_OF_CONDUCT.md).
+
+If you have any questions at all, do not hesitate to reach out to us on
+[Slack](kanisterio.slack.com).
+
+We look forward to working together! 🎈
+
+## Developer Certificate of Origin
+
+To contribute to this project, you must agree to the Developer Certificate of
+Origin (DCO) for each commit you make. The DCO is a simple statement that you,
+as a contributor, have the legal right to make the contribution.
+
+See the [DCO](DCO) file for the full text of what you must agree to.
+
+The most common way to signify your agreement to the DCO is to add a signoff to
+the git commit message, using the `-s` flag of the `git commit` command. It will
+add a signoff the looks like following line to your commit message:
+
+```txt
+Signed-off-by: John Smith <john.smith@example.com>
+```
+
+You must use your real name and a reachable email address in the signoff.
+
+Alternately, instead of commits signoff, you can also leave a comment on the PR
+with the following statement:
+
+> I agree to the DCO for all the commits in this PR.
+
+Note that this option still requires that your commits are made under your real
+name and a reachable email address.
+
+## Contributing Code
+
+### Finding Issues
+
+Generally, pull requests that address and fix existing GitHub issues are assigned
+higher priority over those that don't. Use the existing issue labels to help you
+identify relevant and interesting issues.
+
+If you think something ought to be fixed but none of the existing issues
+sufficiently address the problem, feel free to
+[raise a new one](https://github.com/kanisterio/kanister/issues/new/choose).
+
+For new contributors, we encourage you to tackle issues that are labeled as
+`good first issues`.
+
+Regardless of your familiarity with this project, documentation help is always
+appreciated.
+
+Once you found an issue that interests you, post a comment to the issue, asking
+the maintainers to assign it to you.
+
+### Coding Standard
+
+In this project, we adhere to the style and best practices established by the Go
+project and its community.
+
+Specifically, this means:
+
+* adhering to guidelines found in the [Effective Go](https://go.dev/doc/effective_go) document
+* following the common [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
+
+The [golangci-lint](https://golangci-lint.run/) tool is used to enforce many
+styling and safety rules.
+
+### Creating A Local Build
+
+See the [BUILD.md](BUILD.md) document for instructions on how to build, test and
+run Kanister locally.
+
+### Commit messages
+
+The basic idea is that we ask all contributors to practice
+[good git commit hygiene](https://www.futurelearn.com/info/blog/telling-stories-with-your-git-history)
+to make reviews and retrospection easy. Use your git commits to provide context
+for the reviewers, and the folks who will be reading the codebase in the months
+and years to come.
+
+Finalized commit messages should look similar to the following format:
+
+```text
+Short one line title
+
+An explanation of the problem, providing context, and why the change is being
+made.
+```
+
+### Submitting Pull Requests
+
+When submitting a pull request, it's important that you communicate your intent,
+by clearly:
+
+1. describing the problem you are trying to solve with links to the relevant
+GitHub issues
+1. describing your solution with links to any design documentation and
+discussion
+1. defining how you test and validate your solution
+1. updating the relevant documentation and examples where appropriate
+
+The pull request template is designed to help you convey this information.
+
+In general, smaller pull requests are easier to review and merge than bigger
+ones. It's always a good idea to collaborate with the maintainers to determine
+how best to break up a big pull request.
+
+Once the maintainers approve your PR, they will label it as `kueue`. The
+`mergify` bot will then squash the commits in your PR, and add it to the merge
+queue. The bot will auto-merge your work when it's ready.
+
+Congratulations! Your pull request has been successfully merged! 👏
+
+Thank you for reading through our contributing guide to ensure your
+contributions are high quality and easy for our community to review and accept. 🤝
+
+Please don't hesitate to reach out to us on [Slack](kanisterio.slack.com) if you
+have any questions about contributing!

GOVERNANCE.md

@@ -0,0 +1,50 @@
+# Kanister Governance
+
+This document defines the governance policies of Kanister.
+
+## Contributors
+
+Anyone can contribute to Kanister, whether through code, design discussions,
+documentation, blog posts, talks, or other means. All contributors are expected
+to follow the Kanister [Code of Conduct](CODE_OF_CONDUCT.md).
+
+Contributions to the code base, documentation, or other components in the
+Kanister GitHub organization must follow the guidelines described in the
+[CONTRIBUTING.md](CONTRIBUTING.md) document. Whether these contributions get
+merged into the project is the prerogative of the maintainers.
+
+## Maintainers
+
+Maintainers are responsible for the overall security, quality and integrity of
+the project. They propose, manage, review, approve/reject major change and
+enhancement requests. They also have the ability to merge code into the project.
+See the [MAINTAINERS.md](MAINTAINERS.md) document for the full list of
+maintainer responsibilities.
+
+Ideally, all project decisions are resolved by maintainer consensus. If this
+is not possible, maintainers may call for a vote. The voting process is a simple
+majority in which each maintainer receives one vote.
+
+If a maintainer is no longer interested in or cannot perform the duties listed
+above, they should move themselves to emeritus status. This can also occur by a
+vote of the maintainers.
+
+### Becoming A Maintainer
+
+Anyone can become a Kanister maintainer. Maintainers should be extremely
+proficient in Go; have relevant domain expertise; have the time and ability to
+meet the maintainer expectations outlined above, and demonstrate the ability to
+work with the existing maintainers and project process.
+
+To become a maintainer, start by expressing interest to existing maintainers.
+Existing maintainers will then ask you to demonstrate the qualifications
+above by contributing PRs, doing code reviews, and other such tasks under
+their guidance. After several months of working together, maintainers will
+decide whether to grant maintainer status.
+
+## Updating The Governance
+
+This governance is a living document and its policies will need to be updated
+over time to meet the community's needs. Until the steering committee is set
+up, the maintainers will have full ownership of this governance. Changes can be
+proposed at any time, but a super majority is required to approve any updates.

MAINTAINERS.md

@@ -0,0 +1,65 @@
+# Overview
+
+This document provides information on who the Kanister maintainers are, and
+their responsibilities. If you're interested in contributing, see the
+[CONTRIBUTING](CONTRIBUTING.md) guide.
+
+## Maintainers
+
+These are the current Kanister maintainers:
+
+* Tom Manville @tdmanv
+* Pavan Navarathna @pavannd1
+* Prasad Ghangal @PrasadG193
+* Vivek Singh @viveksinghggits
+* Ivan Sim @ihcsim
+
+## Maintainer Responsibilities
+
+Maintainers are active and visible members of the community. They have a lot of
+experience with the project and are expected to have the knowledge and
+insight to lead its growth and improvement.
+
+This section describes their responsibilities.
+
+### Uphold Code of Conduct
+
+Uphold the values and behavior set forward by the
+[Code of Conduct](CODE_OF_CONDUCT.md) to ensure a safe and welcoming community.
+
+### Prioritize Security
+
+Prioritize reported security vulnerabilities and ensure that they are addressed
+before features or bugs. See the project's [security policy](SECURITY.md).
+
+### Review Pull Requests
+
+Review pull requests regularly with comments, suggestions, decision to reject,
+merge or close them. Accept only high quality pull requests. Provide code
+reviews and guidance on incoming pull requests to adhere to established
+standards, best practices and guidelines.
+
+### Triage Open Issues
+
+Review issues regularly to determine their priority and relevance, with proper
+labeling to identify milestones, blockers, complexity, entry-level issues etc.
+
+### Be Responsive
+
+Respond to Slack messages, enhancement requests, and forum posts. Allocate time
+to reviewing and commenting on issues and conversations as they come in.
+
+### Maintain Overall System Quality
+
+Maintain healthy test coverage and code quality report score. Avoid dependency
+bloat. Mitigate breaking changes.
+
+### Manage Releases
+
+Make frequent project releases to the community. Keep the release branch at
+production quality at all times. Backport features as needed. Cut release
+branches and tags to enable future patches.
+
+### Attend Community Meetings
+
+Regularly promote and attend the recurring Kanister community meetings.

SECURITY.md

@@ -1,9 +1,5 @@
 # Security Policy
 
-## Supported Versions
-
-To be confirmed.
-
 ## Reporting a Vulnerability
 
 To report a security problem in Kanister, please contact the maintainers listed