Merge pull request clusterlink-net#53 from elevran/cncf_project_files

[open source]: add recommended CNCF project files

CODE_OF_CONDUCT.md

@@ -0,0 +1,6 @@
+# Code of Conduct
+
+We follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).
+
+Please contact the [CNCF Code of Conduct Committee](mailto:conduct@cncf.io)
+in order to report violations of the Code of Conduct.

CONTRIBUTING.md

@@ -0,0 +1,142 @@
+# Contributing Guide
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#introduction)
+
+* [New Contributor Guide](#contributing-guide)
+  * [Ways to Contribute](#ways-to-contribute)
+  * [Find an Issue](#find-an-issue)
+  * [Ask for Help](#ask-for-help)
+  * [Pull Request Lifecycle](#pull-request-lifecycle)
+  * [Development Environment Setup](#development-environment-setup)
+  * [Sign Your Commits](#sign-your-commits)
+  * [Pull Request Checklist](#pull-request-checklist)
+
+Welcome! We are glad that you want to contribute to our project! 💖
+
+As you get started, you are in the best position to give us feedback on areas of
+our project that we need help with including:
+
+* Problems found during setting up a new developer environment
+* Gaps in our Quickstart Guide or documentation
+* Bugs in our automation scripts
+
+If anything doesn't make sense, or doesn't work when you run it, please open a
+bug report and let us know!
+
+## Ways to Contribute
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#ways-to-contribute)
+
+We welcome many different types of contributions including:
+
+* New features
+* Builds, CI/CD
+* Bug fixes
+* Documentation
+* Issue Triage
+* Answering questions on Slack/Mailing List
+* Web design
+* Communications / Social Media / Blog Posts
+* Release management
+
+<!--
+Not everything happens through a GitHub pull request. Please come to our
+[meetings](TODO) or [contact us](TODO) and let's discuss how we can work
+together. -->
+
+<!--
+### Come to Meetings
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#come-to-meetings)
+
+Absolutely everyone is welcome to come to any of our meetings. You never need an
+invite to join us. In fact, we want you to join us, even if you don’t have
+anything you feel like you want to contribute. Just being there is enough!
+
+You can find out more about our meetings [here](TODO). You don’t have to turn on
+your video. The first time you come, introducing yourself is more than enough.
+Over time, we hope that you feel comfortable voicing your opinions, giving
+feedback on others’ ideas, and even sharing your own ideas, and experiences.
+-->
+
+## Find an Issue
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#find-an-issue)
+
+We have good first issues for new contributors and help wanted issues suitable
+for any contributor. [good first issue](TODO) has extra information to
+help you make your first contribution. [help wanted](TODO) are issues
+suitable for someone who isn't a core maintainer and is good to move onto after
+your first pull request.
+
+<!-- 
+Sometimes there won’t be any issues with these labels. That’s ok! There is
+likely still something for you to work on. If you want to contribute but you
+don’t know where to start or can't find a suitable issue, you can ⚠️ **explain how people can ask for an issue to work on**.
+-->
+
+Once you see an issue that you'd like to work on, please post a comment saying
+that you want to work on it. Something like "I want to work on this" is fine.
+
+## Ask for Help
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#ask-for-help)
+
+The best way to reach us with a question when contributing is to ask on:
+
+<!-- ⚠️ **Pick the way(s) that you prefer people ask for help** -->
+
+* The original github issue
+* The developer mailing list
+* Our Slack channel
+
+## Pull Request Lifecycle
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#pull-request-lifecycle)
+
+<!-- ⚠️ **Explain your pull request process** -->
+
+## Development Environment Setup
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#development-environment-setup)
+
+<!-- ⚠️ **Explain how to set up a development environment** -->
+
+## Sign Your Commits
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/contributing/#sign-your-commits)
+
+### DCO
+
+Licensing is important to open source projects. It provides some assurances that
+the software will continue to be available based under the terms that the
+author(s) desired. We require that contributors sign off on commits submitted to
+our project's repositories. The [Developer Certificate of Origin
+(DCO)](https://probot.github.io/apps/dco/) is a way to certify that you wrote and
+have the right to contribute the code you are submitting to the project.
+
+You sign-off by adding the following to your commit messages. Your sign-off must
+match the git user and email associated with the commit.
+
+    This is my commit message
+
+    Signed-off-by: Your Name <your.name@example.com>
+
+Git has a `-s` command line option to do this automatically:
+
+    git commit -s -m 'This is my commit message'
+
+If you forgot to do this and have not yet pushed your changes to the remote
+repository, you can amend your commit with the sign-off by running 
+
+    git commit --amend -s 
+
+## Pull Request Checklist
+
+When you submit your pull request, or you push new commits to it, our automated
+systems will run some checks on your new code. We require that your pull request
+passes these checks, but we also have more criteria than just that before we can
+accept and merge it. We recommend that you check the following things locally
+before you submit your code:
+
+<!-- ⚠️ **Create a checklist that authors should use before submitting a pull request** -->

GOVERNANCE.md

@@ -0,0 +1,157 @@
+# ClusterLink Project Governance
+
+[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-maintainer/)
+
+The ClusterLink project is dedicated to creating multicloud Service interconnect fabric.
+This governance explains how the project is run.
+
+- [Values](#values)
+- [Maintainers](#maintainers)
+- [Becoming a Maintainer](#becoming-a-maintainer)
+- [Meetings](#meetings)
+- [Code of Conduct Enforcement](#code-of-conduct)
+- [Security Response Team](#security-response-team)
+- [Voting](#voting)
+- [Modifications](#modifying-this-charter)
+
+## Work In Progress
+
+This document is work in progress and has several incomplete items that need resolution.
+The items are mostly marked in the text as `[TODO:Some action]`:
+
+-[ ] Populate maintainers list
+-[ ] Decide on criteria for becoming a maintainer
+-[ ] Mailing list creation and management
+-[ ] Project meeting schedule
+-[ ] Security response team and issue handling
+
+## Values
+
+The ClusterLink and its leadership embrace the following values:
+
+- Openness: Communication and decision-making happens in the open and is discoverable for
+ future reference. As much as possible, all discussions and work take place in public
+ forums and open repositories.
+
+- Fairness: All stakeholders have the opportunity to provide feedback and submit
+ contributions, which will be considered on their merits.
+
+- Community over Product or Company: Sustaining and growing our community takes
+ priority over shipping code or sponsors' organizational goals.  Each contributor
+ participates in the project as an individual.
+
+- Inclusivity: We innovate through different perspectives and skill sets, which
+  can only be accomplished in a welcoming and respectful environment.
+
+- Participation: Responsibilities within the project are earned through
+  participation, and there is a clear path up the contributor ladder into leadership
+  positions.
+
+## Maintainers
+
+ClusterLink Maintainers have write access to the [clusterlink-net/clusterlink](https://github.com/clusterlink-net/clusterlink) repository.
+They can merge their own patches or patches from others. The current maintainers
+can be found in [MAINTAINERS.md](./MAINTAINERS.md). Maintainers collectively manage the
+project's resources and contributors.
+
+This privilege is granted with some expectation of responsibility: maintainers
+are people who care about the ClusterLink project and want to help it grow and
+improve. A maintainer is not just someone who can make changes, but someone who
+has demonstrated their ability to collaborate with the team, get the most
+knowledgeable people to review code and docs, contribute high-quality code, and
+follow through to fix issues (in code or tests).
+
+A maintainer is a contributor to the project's success and a citizen helping
+the project succeed.
+
+The collective team of all Maintainers is known as the Maintainer Council, which
+is the governing body for the project.
+
+### Becoming a Maintainer
+
+To become a Maintainer you need to demonstrate the following:
+
+- commitment to the project:
+  - participate in discussions, contributions, code and documentation reviews
+      for [TODO:Period] or more,
+  - perform reviews for [TODO:Number] non-trivial pull requests,
+  - contribute [TODO:Number] non-trivial pull requests and have them merged,
+- ability to write quality code and/or documentation,
+  - ability to collaborate with the team,
+  - understanding of how the team works (policies, processes for testing and code review, etc),
+  - understanding of the project's code base and coding and documentation style.
+  <!-- add any additional Maintainer requirements here -->
+
+A new Maintainer must be proposed by an existing maintainer by sending a message to the
+[developer mailing list](TODO: List Link). A simple majority vote of existing Maintainers
+approves the application.  Maintainers nominations will be evaluated without prejudice
+to employer or demographics.
+
+Maintainers who are selected will be granted the necessary GitHub rights,
+and invited to the [private maintainer mailing list](TODO).
+
+### Removing a Maintainer
+
+Maintainers may resign at any time if they feel that they will not be able to
+continue fulfilling their project duties.
+
+Maintainers may also be removed after being inactive, failure to fulfill their
+Maintainer responsibilities, violating the Code of Conduct, or other reasons.
+Inactivity is defined as a period of very low or no activity in the project
+for a year or more, with no definite schedule to return to full Maintainer
+activity.
+
+A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
+
+Depending on the reason for removal, a Maintainer may be converted to Emeritus
+status.  Emeritus Maintainers will still be consulted on some project matters,
+and can be rapidly returned to Maintainer status if their availability changes.
+
+## Meetings
+
+Time zones permitting, Maintainers are expected to participate in the public
+developer meeting, which occurs
+[TODO: Details of regular developer or maintainer meeting here].  
+
+Maintainers will also have closed meetings in order to discuss security reports
+or Code of Conduct violations.  Such meetings should be scheduled by any
+Maintainer on receipt of a security issue or CoC report.  All current Maintainers
+must be invited to such closed meetings, except for any Maintainer who is
+accused of a CoC violation.
+
+## Code of Conduct
+
+[Code of Conduct](./code-of-conduct.md)
+violations by community members will be discussed and resolved
+on the [private Maintainer mailing list](TODO). If a Maintainer is directly involved
+in the report, the Maintainers will instead designate two Maintainers to work
+with the CNCF Code of Conduct Committee in resolving it.
+
+## Security Response Team
+
+The Maintainers will appoint a Security Response Team to handle security reports.
+This committee may simply consist of the Maintainer Council themselves.  If this
+responsibility is delegated, the Maintainers will appoint a team of at least two
+contributors to handle it.  The Maintainers will review who is assigned to this
+at least once a year.
+
+The Security Response Team is responsible for handling all reports of security
+holes and breaches according to the [security policy](TODO:Link to security.md).
+
+## Voting
+
+While most business in ClusterLink is conducted by "[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)",
+periodically the Maintainers may need to vote on specific actions or changes.
+A vote can be taken on [the developer mailing list](TODO) or
+[the private Maintainer mailing list](TODO) for security or conduct matters.  
+Votes may also be taken at [the developer meeting](TODO).  Any Maintainer may
+demand a vote be taken.
+
+Most votes require a simple majority of all Maintainers to succeed, except where
+otherwise noted.  Two-thirds majority votes mean at least two-thirds of all
+existing maintainers.
+
+## Modifying this Charter
+
+Changes to this Governance and its supporting documents may be approved by
+a 2/3 vote of the Maintainers.