Skip to content

Commit 0d88fe3

Browse files
github-actions[bot]github-actions[bot]
authored
ci(.github): automatic sync of files in kumahq/.github (#210)
Signed-off-by: GitHub <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
1 parent 003ca9e commit 0d88fe3

File tree

6 files changed

+396
-3
lines changed

6 files changed

+396
-3
lines changed

‎CODEOWNERS

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
# Default for any repo in kumahq, synced from kumahq/.github
2+
3+
* @kumahq/kuma-maintainers

‎CODE_OF_CONDUCT.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,5 @@
1+
<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
2+
13
# Kuma Community Code of Conduct
24

35
Kuma follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

‎CONTRIBUTING.md

Lines changed: 145 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,145 @@
1+
<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
2+
# Contributing Guide
3+
4+
* [New Contributor Guide](#contributing-guide)
5+
* [Ways to Contribute](#ways-to-contribute)
6+
* [Find an Issue](#find-an-issue)
7+
* [Ask for Help](#ask-for-help)
8+
* [Pull Request Lifecycle](#pull-request-lifecycle)
9+
* [Development Environment Setup](#development-environment-setup)
10+
* [Sign Your Commits](#sign-your-commits)
11+
* [Pull Request Checklist](#pull-request-checklist)
12+
13+
Welcome! We are glad that you want to contribute to Kuma! 💖
14+
15+
As you get started, you are in the best position to give us feedback on areas of
16+
our project that we need help with including:
17+
18+
* Problems found during setting up a new developer environment
19+
* Gaps in our Quickstart Guide or documentation
20+
* Bugs in our automation scripts
21+
22+
If anything doesn't make sense, or doesn't work when you run it, please open a
23+
bug report and let us know!
24+
25+
## Ways to Contribute
26+
27+
We welcome many types of contributions including:
28+
29+
* New features
30+
* Builds, CI/CD
31+
* Bug fixes
32+
* Documentation
33+
* Issue Triage
34+
* Answering questions on Slack/Mailing List
35+
* Web design
36+
* Communications / Social Media / Blog Posts
37+
* Release management
38+
39+
Not everything happens through a GitHub pull request. Please check
40+
the [community page on kuma.io](https://kuma.io/community/).
41+
42+
### Come to meetings!
43+
Absolutely everyone is welcome to come to any of our meetings. You never need an
44+
invitation to join us. In fact, we want you to join us, even if you don’t have
45+
anything you feel like you want to contribute. Just being there is enough!
46+
47+
You can find out more about our meetings [here](https://kuma.io/community/).
48+
You don’t have to turn on your video.
49+
The first time you come, introducing yourself is more than enough.
50+
Over time, we hope that you feel comfortable voicing your opinions, giving
51+
feedback on others’ ideas, and even sharing your own ideas, and experiences.
52+
53+
## Find an Issue
54+
55+
We have good first issues for new contributors and help wanted issues suitable
56+
for any contributor.
57+
[good first issue](https://github.com/search?q=org%3Akumahq+label%3A%22good+first+issue%22+state%3Aopen&type=Issues) has extra information to
58+
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
59+
suitable for someone who isn't a core maintainer and is good to move onto after
60+
your first pull request.
61+
62+
Sometimes there won’t be any issues with these labels. That’s ok! There is
63+
likely still something for you to work on. If you want to contribute but you
64+
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/).
65+
66+
Once you see an issue that you'd like to work on, please post a comment saying
67+
that you want to work on it. Something like "I want to work on this" is fine.
68+
69+
You might want to familiarize yourself with our [Triage policy](https://github.com/kumahq/.github/blob/main/PROJECT_MANAGEMENT.md#triage).
70+
71+
## Ask for Help
72+
73+
The best way to reach us with a question when contributing is to ask on:
74+
75+
* The original github issue
76+
* The developer mailing list
77+
* [Kuma Slack #developer](https://join.slack.com/t/kuma-mesh/shared_invite/zt-1rcll3y6t-DkV_CAItZUoy0IvCwQ~jlQ)
78+
79+
80+
## Pull Request Lifecycle
81+
82+
- Use freely Draft PRs but don't except anyone to review or look at it unless you explicitly mention them.
83+
- If you create a regular PR, reviewers will review it so only open PRs that are ready to review.
84+
- If no-one reviews your PR it's ok to ping folks in Slack after 2 business days.
85+
- The reviewer will leave feedback and follow these rules:
86+
- nits: These are suggestions that you may decide incorporate into your pull request or not without further comment.
87+
- It can help to put a 👍 on comments that you have implemented so that you can keep track.
88+
- It is okay to clarify if you are being told to make a change or if it is a suggestion.
89+
- 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.
90+
- Ask for a new review by dismissing existing reviews and/or mention the reviewer.
91+
- Please wait 2 business days before pinging the reviewer again.
92+
- 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.
93+
94+
## Development Environment Setup
95+
96+
See [the dedicated page](./DEVELOPER.md).
97+
98+
## Sign Your Commits
99+
100+
### DCO
101+
Licensing is important to open source projects. It provides some assurances that
102+
the software will continue to be available based under the terms that the
103+
author(s) desired. We require that contributors sign off on commits submitted to
104+
our project's repositories. The [Developer Certificate of Origin
105+
(DCO)](https://developercertificate.org/) is a way to certify that you wrote and
106+
have the right to contribute the code you are submitting to the project.
107+
108+
You sign-off by adding the following to your commit messages. Your sign-off must
109+
match the git user and email associated with the commit.
110+
111+
This is my commit message
112+
113+
Signed-off-by: Your Name <[email protected]>
114+
115+
Git has a `-s` command line option to do this automatically:
116+
117+
git commit -s -m 'This is my commit message'
118+
119+
If you forgot to do this and have not yet pushed your changes to the remote
120+
repository, you can amend your commit with the sign-off by running
121+
122+
git commit --amend -s
123+
124+
125+
## Pull Request Checklist
126+
127+
When you submit your pull request, or you push new commits to it, our automated
128+
systems will run some checks on your new code. We require that your pull request
129+
passes these checks, but we also have more criteria than just that before we can
130+
accept and merge it. We recommend that you check the following things locally
131+
before you submit your code:
132+
133+
**TODO**
134+
<!-- list both the automated and any manual checks performed by reviewers, it
135+
is very helpful when the validations are automated in a script for example in a
136+
Makefile target. Below is an example of a checklist:
137+
138+
* It passes tests: run the following command to run all of the tests locally:
139+
`make build test lint`
140+
* Impacted code has new or updated tests
141+
* Documentation created/updated
142+
* We use [Azure DevOps, GitHub Actions, CircleCI] to test all pull
143+
requests. We require that all tests succeed on a pull request before it is merged.
144+
145+
-->

‎GOVERNANCE.md

Lines changed: 145 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,145 @@
1+
<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
2+
# Kuma Governance
3+
4+
This document defines governance policies for the Kuma project.
5+
6+
Anyone can become a Kuma contributor simply by contributing to the project, with code, documentation or other means.
7+
As with all Kuma community members, contributors are expected to follow
8+
the [Kuma Code of Conduct](./CODE_OF_CONDUCT.md).
9+
10+
## Voting
11+
12+
All changes are always initiated either by issue creation (organization members) or pull requests (governance, maintainership).
13+
Votes take place using the https://github.com/cncf/gitvote application (Already installed in the kumahq organization).
14+
15+
## Steering committee
16+
17+
Steering committee members demonstrate a strong commitment to the project with views in the interest of the broader Kuma
18+
community.
19+
They are the stewards of the entire Kuma organization and are expected to dedicate thoughtful and serious effort towards
20+
the goal of general success in the ecosystem.
21+
22+
Responsibilities include:
23+
24+
- Own the overall vision of the Kuma project
25+
- Provide guidance to maintainers
26+
- Review and approve core architecture and design changes
27+
- Add/Remove members and approve deleting or archiving repositories in the Kumahq organization
28+
- Regularly attend community meetings
29+
- Facilitate community process (votes, process changes...)
30+
31+
The list of members of the steering committee are in [OWNERS.md](./OWNERS.md). All steering committee members are owners
32+
of the Kumahq github organization.
33+
34+
### Bootstrapping the committee
35+
36+
The bootstrapped committee will consist of the 3 most active committers namely:
37+
38+
- [Jakub Dyszkiewicz](https://github.com/jakubdyszkiewicz)
39+
- [Michael Beaumont](https://github.com/michaelbeaumont)
40+
- [Charly Molter](https://github.com/lahabana)
41+
42+
### Changes to the steering committee
43+
44+
- Members are elected for 2 years.
45+
- Members can step down by submitting an update to [OWNERS.md](./OWNERS.md)
46+
- Reelection and new members are accepted after a 6 weeks voting period and super majority of the steering committee is
47+
required (at least 2/3 of votes) to make changes.
48+
49+
50+
## Maintainership
51+
52+
The Kuma project consists of multiple repositories.
53+
Each repository is subject to the same governance model, but different maintainers and reviewers.
54+
55+
### Maintainers
56+
57+
Maintainers have write access to the repo.
58+
The current maintainers of a repo can be found in [OWNERS.md](./OWNERS.md) file of the repo.
59+
60+
Maintainers have the most experience with the given repo and are expected to lead its growth and improvement.
61+
Adding and removing maintainers for a given repo is the responsibility of the existing maintainer team for that repo and
62+
therefore does not require approval from the steering committee
63+
64+
This privilege is granted with some expectation of responsibility: maintainers are people who care about the Kuma
65+
project and want to help it grow and improve.
66+
A maintainer is not just someone who can make changes, but someone who has demonstrated his or her ability to
67+
collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, and follow
68+
through to fix issues (in code or tests).
69+
70+
#### Becoming a Maintainer
71+
72+
To become a maintainer you need to demonstrate the following:
73+
74+
* commitment to the project
75+
* participate in discussions, contributions, code reviews for substantial time
76+
* perform code reviews on non-trivial pull requests,
77+
* contribute to non-trivial pull requests and have them merged into master,
78+
* ability to write good code,
79+
* ability to collaborate with the team,
80+
* understanding of how the team works (policies, processes for testing and code review, etc),
81+
* understanding of the project's code base and coding style.
82+
83+
### Reviewers
84+
85+
Each repository can have a list of reviewers.
86+
Reviewers help maintainers review new contributions.
87+
They're typically newer to the project and interested in working toward becoming a maintainer.
88+
Reviewers may approve but not merge PRs - all PRs must be approved by a maintainer.
89+
90+
The process for adding/removing reviewers is the same as maintainers
91+
92+
The current list of reviewers for each repository (if any) is published and updated in each repo’s OWNERS.md file.
93+
94+
> Note about auto assignment of PR reviewers:
95+
> 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
96+
> teams backing codeowners should be name `<repo>-maintainers` and the matching repo should have an OWNERS.md file with a maintainers section.
97+
> 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).
98+
99+
### Emeritus Maintainers/Reviewers
100+
101+
Any maintainer can become Emeritus maintainer in two ways:
102+
103+
- Asking explicitly by opening a PR to [OWNERS.md](./OWNERS.md) (no vote).
104+
- Someone calling a vote which is open for 5 days with at least one +1 vote for the steering committee and no -1 vote
105+
from the steering committee.
106+
107+
### Changes in Maintainership
108+
A new maintainer can be proposed by opening a PR (with title `Maintainer Nomination`) to the repository containing the following information:
109+
110+
* nominee's first and last name,
111+
* nominee's email address and GitHub user name,
112+
* an explanation of why the nominee should be a maintainer/reviewer (adding links to significant contributions)
113+
114+
At least two maintainers need to agree with the nomination (or all maintainers if there's a single maintainer).
115+
If no one objects in 5 days, the nomination is accepted and PR is merged.
116+
If anyone objects or wants more information, the maintainers discuss and usually come to a consensus.
117+
If issues can't be resolved, there's a simple majority vote among steering committee members.
118+
119+
Maintainers and reviewers can be removed if 2 maintainers approve and none disapprove.
120+
Maintainers and reviewers can leave by just submitting a PR to the repository's OWNERS.md (no vote required in this case).
121+
122+
## Organization members
123+
124+
Organization members are people who have `triage` access to the organization.
125+
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:
126+
127+
- Have enabled 2FA on their GitHub account.
128+
- Have joined the Kuma slack.
129+
- Are actively contributing to the project. Examples include:
130+
- opening issues
131+
- providing feedback on the project
132+
- engaging in discussions on issues, pull requests, Slack, etc.
133+
- attending community meetings
134+
- Have reached out to two current organization members who have agreed to sponsor their membership request.
135+
136+
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.
137+
138+
## Changes in Governance
139+
140+
All changes in Governance require a 2/3 majority vote by the steering committee.
141+
142+
## Other Changes
143+
144+
Unless specified above, all other changes to the project require a 2/3 majority vote by the steering committee.
145+
Additionally, any maintainer may request that any change require a 2/3 majority vote by the steering committee.

‎SECURITY.md

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,14 @@
1+
<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing -->
12
# Security
23

34
## Reporting Vulnerabilities
45

5-
Please report security vulnerabilities by e-mailing:
6+
We use Github's Security advisories for reporting security vulnerabilities.
67

7-
* [[email protected]](mailto:[email protected])
8+
You can open a private report in the [advisories section](https://github.com/kumahq/kuma/security/advisories).
9+
10+
To learn more about this reporting checkout the [Github docs](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability).
811

912
## Public Disclosure
1013

11-
Security vulnerabilities will be disclosed via release notes and issues with severity score higher than [4.0](https://www.first.org/cvss/calculator/3.1) will have an advisory published.
14+
Security vulnerabilities will be disclosed via release notes, issues and Github advisories with severity score higher than [4.0](https://www.first.org/cvss/calculator/3.1) will have an advisory published.

0 commit comments

Comments
 (0)