ci(.github): automatic sync of files in kumahq/.github

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

CODEOWNERS

@@ -1,27 +1,3 @@
-# See https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
+# Default for any repo in kumahq, synced from kumahq/.github
 
-# Code owners are automatically requested for review when someone opens a pull request that modifies code that they own.
-# Code owners are not automatically requested to review draft pull requests.
-
-# When someone with admin or owner permissions has enabled required reviews,
-# they also can optionally require approval from a code owner before the author can merge a pull request in the repository.
-
-# The people you choose as code owners must have write permissions for the repository.
-
-# When the code owner is a team, that team must have write permissions,
-# even if all the individual members of the team already have write permissions directly, 
-# through organization membership, or through another team membership.
-
-# Each CODEOWNERS file assigns the code owners for a single branch in the repository.
-
-# For code owners to receive review requests, the CODEOWNERS file must be on the base branch of the pull request.
-
-# A CODEOWNERS file uses a pattern that follows the same rules used in gitignore files. 
-# The pattern is followed by one or more GitHub usernames or team names using the standard @username or @org/team-name format.
-# You can also refer to a user by an email address that has been added to their GitHub account, for example [email protected].
-
-
-# These owners will be the default owners for everything in this repo.
-# Unless a later match takes precedence, @kumahq/kuma-maintainers will be requested for
-# review when someone opens a pull request.
 *       @kumahq/kuma-maintainers

CODE_OF_CONDUCT.md

@@ -1,3 +1,5 @@
+<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
+
 # Kuma Community Code of Conduct
 
 Kuma follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

CONTRIBUTING.md

@@ -0,0 +1,145 @@
+<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
+# Contributing Guide
+
+* [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 Kuma! 💖
+
+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
+
+We welcome many 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 check
+the [community page on kuma.io](https://kuma.io/community/). 
+
+### Come to meetings!
+Absolutely everyone is welcome to come to any of our meetings. You never need an
+invitation 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](https://kuma.io/community/).
+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
+
+We have good first issues for new contributors and help wanted issues suitable
+for any contributor.
+[good first issue](https://github.com/search?q=org%3Akumahq+label%3A%22good+first+issue%22+state%3Aopen&type=Issues) has extra information to
+help you make your first contribution. [help wanted](https://github.com/search?q=org%3Akumahq+label%3A%22help+wanted%22+state%3Aopen&type=Issues) 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 ask in the #development channel in [the Kuma Slack](https://kuma-mesh.slack.com/).
+
+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.
+
+You might want to familiarize yourself with our [Triage policy](https://github.com/kumahq/.github/blob/main/PROJECT_MANAGEMENT.md#triage).
+
+## Ask for Help
+
+The best way to reach us with a question when contributing is to ask on:
+
+* The original github issue
+* The developer mailing list
+* [Kuma Slack #developer](https://join.slack.com/t/kuma-mesh/shared_invite/zt-1rcll3y6t-DkV_CAItZUoy0IvCwQ~jlQ) 
+
+
+## Pull Request Lifecycle
+
+- Use freely Draft PRs but don't except anyone to review or look at it unless you explicitly mention them.
+- If you create a regular PR, reviewers will review it so only open PRs that are ready to review.
+- If no-one reviews your PR it's ok to ping folks in Slack after 2 business days.
+- The reviewer will leave feedback and follow these rules:
+  - nits: These are suggestions that you may decide incorporate into your pull request or not without further comment.
+  - It can help to put a 👍 on comments that you have implemented so that you can keep track.
+  - It is okay to clarify if you are being told to make a change or if it is a suggestion.
+- Make changes in new commits (Please don't force push to your PR it's easier to review). Please update your PRs it's ok to have merge commits we'll get rid of them when squashing.
+- Ask for a new review by dismissing existing reviews and/or mention the reviewer.
+- Please wait 2 business days before pinging the reviewer again.
+- When a pull request has been approved, the reviewer will squash and merge your commits. If you prefer to rebase your own commits, at any time leave a comment on the pull request to let them know that.
+
+## Development Environment Setup
+
+See [the dedicated page](./DEVELOPER.md).
+
+## 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://developercertificate.org/) 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 <[email protected]>
+
+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:
+
+**TODO**
+<!-- list both the automated and any manual checks performed by reviewers, it
+is very helpful when the validations are automated in a script for example in a
+Makefile target. Below is an example of a checklist:
+
+* It passes tests: run the following command to run all of the tests locally:
+  `make build test lint`
+* Impacted code has new or updated tests
+* Documentation created/updated
+* We use [Azure DevOps, GitHub Actions, CircleCI]  to test all pull
+  requests. We require that all tests succeed on a pull request before it is merged.
+
+-->

GOVERNANCE.md

@@ -1,52 +1,145 @@
+<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
 # Kuma Governance
 
 This document defines governance policies for the Kuma project.
 
-## Maintainers
+Anyone can become a Kuma contributor simply by contributing to the project, with code, documentation or other means.
+As with all Kuma community members, contributors are expected to follow
+the [Kuma Code of Conduct](./CODE_OF_CONDUCT.md).
 
-Kuma Maintainers have write access to the Kuma Demo GitHub repository https://github.com/kumahq/kuma-demo.
-They can merge their own patches or patches from others. The current maintainers can be found in [CODEOWNERS](./CODEOWNERS).
+## Voting
 
-This privilege is granted with some expectation of responsibility: maintainers are people who care about the Kuma project and want to help it grow and improve. A maintainer is not just someone who can make changes, but someone who has demonstrated his or her ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, and follow through to fix issues (in code or tests).
+All changes are always initiated either by issue creation (organization members) or pull requests (governance, maintainership).
+Votes take place using the https://github.com/cncf/gitvote application (Already installed in the kumahq organization).
 
-A maintainer is a contributor to the Kuma project's success and a citizen helping the project succeed.
+## Steering committee
 
-## Becoming a Maintainer
+Steering committee members demonstrate a strong commitment to the project with views in the interest of the broader Kuma
+community.
+They are the stewards of the entire Kuma organization and are expected to dedicate thoughtful and serious effort towards
+the goal of general success in the ecosystem.
+
+Responsibilities include:
+
+- Own the overall vision of the Kuma project
+- Provide guidance to maintainers
+- Review and approve core architecture and design changes
+- Add/Remove members and approve deleting or archiving repositories in the Kumahq organization
+- Regularly attend community meetings
+- Facilitate community process (votes, process changes...)
+
+The list of members of the steering committee are in [OWNERS.md](./OWNERS.md). All steering committee members are owners
+of the Kumahq github organization.
+
+### Bootstrapping the committee
+
+The bootstrapped committee will consist of the 3 most active committers namely:
+
+- [Jakub Dyszkiewicz](https://github.com/jakubdyszkiewicz)
+- [Michael Beaumont](https://github.com/michaelbeaumont)
+- [Charly Molter](https://github.com/lahabana)
+
+### Changes to the steering committee
+
+- Members are elected for 2 years.
+- Members can step down by submitting an update to [OWNERS.md](./OWNERS.md)
+- Reelection and new members are accepted after a 6 weeks voting period and super majority of the steering committee is
+  required (at least 2/3 of votes) to make changes.
+
+
+## Maintainership
+
+The Kuma project consists of multiple repositories.
+Each repository is subject to the same governance model, but different maintainers and reviewers.
+
+### Maintainers
+
+Maintainers have write access to the repo.
+The current maintainers of a repo can be found in [OWNERS.md](./OWNERS.md) file of the repo.
+
+Maintainers have the most experience with the given repo and are expected to lead its growth and improvement.
+Adding and removing maintainers for a given repo is the responsibility of the existing maintainer team for that repo and
+therefore does not require approval from the steering committee
+
+This privilege is granted with some expectation of responsibility: maintainers are people who care about the Kuma
+project and want to help it grow and improve.
+A maintainer is not just someone who can make changes, but someone who has demonstrated his or her ability to
+collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, and follow
+through to fix issues (in code or tests).
+
+#### Becoming a Maintainer
 
 To become a maintainer you need to demonstrate the following:
 
-  * commitment to the project
-    * participate in discussions, contributions, code reviews for 3 months or more,
-    * perform code reviews for 10 non-trivial pull requests,
-    * contribute 10 non-trivial pull requests and have them merged into master,
-  * ability to write good code,
-  * 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 style.
+* commitment to the project
+    * participate in discussions, contributions, code reviews for substantial time
+    * perform code reviews on non-trivial pull requests,
+    * contribute to non-trivial pull requests and have them merged into master,
+* ability to write good code,
+* 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 style.
+
+### Reviewers
+
+Each repository can have a list of reviewers.
+Reviewers help maintainers review new contributions.
+They're typically newer to the project and interested in working toward becoming a maintainer.
+Reviewers may approve but not merge PRs - all PRs must be approved by a maintainer.
+
+The process for adding/removing reviewers is the same as maintainers
+
+The current list of reviewers for each repository (if any) is published and updated in each repo’s OWNERS.md file.
+
+> Note about auto assignment of PR reviewers:
+> For simplicity we use [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) in github
+> teams backing codeowners should be name `<repo>-maintainers` and the matching repo should have an OWNERS.md file with a maintainers section.
+> This avoids keeping maintainers lists in all repos that are closely related (for example all maintainers of kumahq/kuma are also maintainers of kumahq/kuma-tools).
+
+### Emeritus Maintainers/Reviewers
+
+Any maintainer can become Emeritus maintainer in two ways:
+
+- Asking explicitly by opening a PR to [OWNERS.md](./OWNERS.md) (no vote).
+- Someone calling a vote which is open for 5 days with at least one +1 vote for the steering committee and no -1 vote
+  from the steering committee.
+
+### Changes in Maintainership
+A new maintainer can be proposed by opening a PR (with title `Maintainer Nomination`) to the repository containing the following information:
 
-A new maintainer must be proposed by an existing maintainer by opening an issue (with title `Maintainer Nomination`) to the Kuma Github repository (https://github.com/kumahq/kuma) containing the following information:
+* nominee's first and last name,
+* nominee's email address and GitHub user name,
+* an explanation of why the nominee should be a maintainer/reviewer (adding links to significant contributions)
 
-  * nominee's first and last name,
-  * nominee's email address and GitHub user name,
-  * an explanation of why the nominee should be a committer,
-  * a list of links to non-trivial pull requests (top 10) authored by the nominee.
+At least two maintainers need to agree with the nomination (or all maintainers if there's a single maintainer).
+If no one objects in 5 days, the nomination is accepted and PR is merged.
+If anyone objects or wants more information, the maintainers discuss and usually come to a consensus.
+If issues can't be resolved, there's a simple majority vote among steering committee members.
 
-Two other maintainers need to second the nomination. If no one objects in 5 working days (U.S.), the nomination is accepted. If anyone objects or wants more information, the maintainers discuss and usually come to a consensus (within the 5 working days). If issues can't be resolved, there's a simple majority vote among current maintainers.
+Maintainers and reviewers can be removed if 2 maintainers approve and none disapprove. 
+Maintainers and reviewers can leave by just submitting a PR to the repository's OWNERS.md (no vote required in this case).
 
-## Changes in Maintainership
+## Organization members
 
-Maintainers can be removed by a 2/3 majority vote by maintainers.
+Organization members are people who have `triage` access to the organization.
+Community members who wish to become members of the organization should meet the following requirements, which are open to the discretion of the steering committee:
 
-## GitHub Project Administration
+- Have enabled 2FA on their GitHub account.
+- Have joined the Kuma slack.
+- Are actively contributing to the project. Examples include:
+   - opening issues
+   - providing feedback on the project
+   - engaging in discussions on issues, pull requests, Slack, etc.
+   - attending community meetings
+   - Have reached out to two current organization members who have agreed to sponsor their membership request.
 
-Maintainers will be added to the GitHub @kumahq/kuma-maintainers team, and made a GitHub maintainer of that team.
-They will be given write permission to the Kuma Demo GitHub repository https://github.com/kumahq/kuma-demo.
+To do so they need to open an issue in kumahq/kuma showing that they fill the above requirements. Sponsors express their support by adding `+1` as a comment.
 
 ## Changes in Governance
 
-All changes in Governance require a 2/3 majority vote by maintainers.
+All changes in Governance require a 2/3 majority vote by the steering committee.
 
 ## Other Changes
 
-Unless specified above, all other changes to the project require a 2/3 majority vote by maintainers.
-Additionally, any maintainer may request that any change require a 2/3 majority vote by maintainers.
+Unless specified above, all other changes to the project require a 2/3 majority vote by the steering committee.
+Additionally, any maintainer may request that any change require a 2/3 majority vote by the steering committee.

SECURITY.md

@@ -1,3 +1,4 @@
+<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
 # Security
 
 ## Reporting Vulnerabilities