You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explains how Maintainers are selected and their responsibilities.
Explains the Pull Request review workflow.
Adds config for Mergify to enforce this workflow.
Signed-off-by: Dave Tucker <[email protected]>
If you want to make changes to the Aya Book, see the readme in the book repo
25
-
https://github.com/aya-rs/book.
25
+
We welcome many different types of contributions including:
26
26
27
-
## Fixing bugs and implementing new features
27
+
* New features
28
+
* Builds, CI/CD
29
+
* Bug fixes
30
+
* Documentation
31
+
* Issue Triage
32
+
* Answering questions on Discord
33
+
* Web design
34
+
* Communications / Social Media / Blog Posts
35
+
* Release management
28
36
29
-
Make sure that your work is tracked by an issue or a (draft) pull request, this
30
-
helps us avoid duplicating work. If your work includes publicly visible changes,
31
-
make sure those are properly documented as explained in the section above.
37
+
Not everything happens through a GitHub pull request. Please come to our
38
+
[Discord](https://discord.gg/xHW2cb2N6G) and let's discuss how we can work
39
+
together.
32
40
33
-
### Running tests
34
-
Run the unit tests with `cargo test`. See [Aya Integration Tests](https://github.com/aya-rs/aya/blob/main/test/README.md) regarding running the integration tests.
41
+
## Find an Issue
35
42
36
-
### Commits
43
+
We have good first issues for new contributors and help wanted issues suitable
44
+
for any contributor. [good first issue](https://github.com/aya-rs/aya/labels/good%20first%20issue) has extra information to
45
+
help you make your first contribution. [help wanted](https://github.com/aya-rs/aya/labels/help%20wanted) are issues
46
+
suitable for someone who isn't a core maintainer and is good to move onto after
47
+
your first pull request.
48
+
49
+
Sometimes there won’t be any issues with these labels. That’s ok! There is
50
+
likely still something for you to work on. If you want to contribute but you
51
+
don’t know where to start or can't find a suitable issue, you can reach out to us on Discord and we will be happy to help.
52
+
53
+
Once you see an issue that you'd like to work on, please post a comment saying
54
+
that you want to work on it. Something like "I want to work on this" is fine.
55
+
56
+
## Ask for Help
57
+
58
+
The best way to reach us with a question when contributing is to ask on:
59
+
60
+
* The original github issue
61
+
* Our Discord
62
+
63
+
## Pull Request Lifecycle
64
+
65
+
Pull requests are managed by Mergify.
66
+
67
+
Our process is currently as follows:
68
+
69
+
1. When you open a PR a maintainer will automatically be assigned for review
70
+
1. Make sure that your PR is passing CI - if you need help with failing checks please feel free to ask!
71
+
1. Once it is passing all CI checks, a maintainer will review your PR and you may be asked to make changes.
72
+
1. When you have received at two approving reviews from a maintainer, your PR will be merged automiatcally.
73
+
74
+
In some cases, other changes may conflict with your PR. If this happens, you will get notified by a comment in the issue that your PR requires a rebase, and the `needs-rebase` label will be applied. Once a rebase has been performed, this label will be automatically removed.
75
+
76
+
## Signoff Your Commits
77
+
78
+
### DCO
79
+
80
+
Licensing is important to open source projects. It provides some assurances that
81
+
the software will continue to be available based under the terms that the
82
+
author(s) desired. We require that contributors sign off on commits submitted to
83
+
our project's repositories. The [Developer Certificate of Origin
84
+
(DCO)](https://probot.github.io/apps/dco/) is a way to certify that you wrote and
85
+
have the right to contribute the code you are submitting to the project.
86
+
87
+
You sign-off by adding the following to your commit messages. Your sign-off must
88
+
match the git user and email associated with the commit.
Git has a `-s` command line option to do this automatically:
95
+
96
+
git commit -s -m 'This is my commit message'
97
+
98
+
If you forgot to do this and have not yet pushed your changes to the remote
99
+
repository, you can amend your commit with the sign-off by running
100
+
101
+
git commit --amend -s
102
+
103
+
## Logical Grouping of Commits
37
104
38
105
It is a recommended best practice to keep your changes as logically grouped as
39
106
possible within individual commits. If while you're developing you prefer doing
40
107
a number of commits that are "checkpoints" and don't represent a single logical
41
108
change, please squash those together before asking for a review.
109
+
When addressing review comments, please perform an interactive rebase and edit commits directly rather than adding new commits with messages like "Fix review comments".
42
110
43
-
####Commit message guidelines
111
+
## Commit message guidelines
44
112
45
113
A good commit message should describe what changed and why.
46
114
47
115
1. The first line should:
48
-
49
-
* contain a short description of the change (preferably 50 characters or less,
116
+
117
+
* contain a short description of the change (preferably 50 characters or less,
50
118
and no more than 72 characters)
51
-
* be entirely in lowercase with the exception of proper nouns, acronyms, and
119
+
* be entirely in lowercase with the exception of proper nouns, acronyms, and
52
120
the words that refer to code, like function/variable names
53
-
* be prefixed with the name of the sub crate being changed
121
+
* be prefixed with the name of the sub crate being changed
54
122
55
123
Examples:
56
124
57
-
* aya: handle reordered functions
58
-
* aya-bpf: SkSkbContext: add ::l3_csum_replace
125
+
* aya: validate program section names
126
+
* aya-bpf: add dispatcher program test slot
59
127
60
128
2. Keep the second line blank.
61
129
3. Wrap all other lines at 72 columns (except for long URLs).
@@ -66,8 +134,8 @@ A good commit message should describe what changed and why.
66
134
67
135
Examples:
68
136
69
-
-`Fixes: #1337`
70
-
-`Refs: #1234`
137
+
*`Fixes: #1337`
138
+
*`Refs: #1234`
71
139
72
140
Sample complete commit message:
73
141
@@ -86,3 +154,16 @@ nicely even when it is indented.
86
154
Fixes: #1337
87
155
Refs: #453, #154
88
156
```
157
+
158
+
## Pull Request Checklist
159
+
160
+
When you submit your pull request, or you push new commits to it, our automated
161
+
systems will run some checks on your new code. We require that your pull request
162
+
passes these checks, but we also have more criteria than just that before we can
163
+
accept and merge it. We recommend that you check the following things locally
164
+
before you submit your code:
165
+
166
+
* That Rust code has been formatted with `cargo +nightly fmt` and that all clippy lints have been fixed - you can find failing lints with `cargo +nightly clippy`
167
+
* That Go code has been formatted and linted
168
+
* That unit tests are passing locally with `cargo test`
169
+
* That integration tests are passing locally `cargo xtask integration-test`
The Aya project is dedicated to creating the best user experience when using eBPF from Rust, whether that's in user-land or kernel-land. This governance explains how the project is run.
The Aya project and its leadership embrace the following values:
17
+
18
+
- Openness: Communication and decision-making happens in the open and is discoverable for future
19
+
reference. As much as possible, all discussions and work take place in public
20
+
forums and open repositories.
21
+
22
+
- Fairness: All stakeholders have the opportunity to provide feedback and submit
23
+
contributions, which will be considered on their merits.
24
+
25
+
- Community over Product or Company: Sustaining and growing our community takes
26
+
priority over shipping code or sponsors' organizational goals. Each
27
+
contributor participates in the project as an individual.
28
+
29
+
- Inclusivity: We innovate through different perspectives and skill sets, which
30
+
can only be accomplished in a welcoming and respectful environment.
31
+
32
+
- Participation: Responsibilities within the project are earned through
33
+
participation, and there is a clear path up the contributor ladder into leadership
34
+
positions.
35
+
36
+
## Maintainers
37
+
38
+
Aya Maintainers have write access to the [all projects in the GitHub organization](https://github.com/aya-rs).
39
+
They can merge their patches or patches from others. The list of current maintainers
40
+
can be found at [MAINTAINERS.md](./MAINTAINERS.md). Maintainers collectively manage the project's
41
+
resources and contributors.
42
+
43
+
This privilege is granted with some expectation of responsibility: maintainers
44
+
are people who care about the Aya project and want to help it grow and
45
+
improve. A maintainer is not just someone who can make changes, but someone who
46
+
has demonstrated their ability to collaborate with the team, get the most
47
+
knowledgeable people to review code and docs, contribute high-quality code, and
48
+
follow through to fix issues (in code or tests).
49
+
50
+
A maintainer is a contributor to the project's success and a citizen helping
51
+
the project succeed.
52
+
53
+
The collective team of all Maintainers is known as the Maintainer Council, which
54
+
is the governing body for the project.
55
+
56
+
### Becoming a Maintainer
57
+
58
+
To become a Maintainer you need to demonstrate the following:
59
+
60
+
- commitment to the project:
61
+
- participate in discussions, contributions, code and documentation reviews, for 6 months or more,
62
+
- perform reviews for 10 non-trivial pull requests,
63
+
- contribute 10 non-trivial pull requests and have them merged,
64
+
- ability to write quality code and/or documentation,
65
+
- ability to collaborate with the team,
66
+
- understanding of how the team works (policies, processes for testing and code review, etc),
67
+
- understanding of the project's code base and coding and documentation style.
68
+
69
+
A new Maintainer must be proposed by an existing maintainer by opening a Pull Request on GitHub to update the MAINTAINERS.md file. A simple majority vote of existing Maintainers
70
+
approves the application. Maintainer nominations will be evaluated without prejudice
71
+
to employers or demographics.
72
+
73
+
Maintainers who are selected will be granted the necessary GitHub rights.
74
+
75
+
### Removing a Maintainer
76
+
77
+
Maintainers may resign at any time if they feel that they will not be able to
78
+
continue fulfilling their project duties.
79
+
80
+
Maintainers may also be removed after being inactive, failing to fulfill their
81
+
Maintainer responsibilities, violating the Code of Conduct, or for other reasons.
82
+
Inactivity is defined as a period of very low or no activity in the project
83
+
for a year or more, with no definite schedule to return to full Maintainer
84
+
activity.
85
+
86
+
A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
87
+
88
+
Depending on the reason for removal, a Maintainer may be converted to Emeritus
89
+
status. Emeritus Maintainers will still be consulted on some project matters
90
+
and can be rapidly returned to Maintainer status if their availability changes.
91
+
92
+
## Meetings
93
+
94
+
There are no standing meetings for Maintainers.
95
+
96
+
Maintainers will also have closed meetings to discuss security reports
97
+
or Code of Conduct violations. Such meetings should be scheduled by any
98
+
Maintainer on receipt of a security issue or CoC report. All current Maintainers
99
+
must be invited to such closed meetings, except for any Maintainer who is
100
+
accused of a CoC violation.
101
+
102
+
## Code of Conduct
103
+
104
+
[Code of Conduct](./CODE_OF_CONDUCT.md) violations by community members will be discussed and resolved on the private maintainer Discord channel.
105
+
106
+
## Security Response Team
107
+
108
+
The Maintainers will appoint a Security Response Team to handle security reports.
109
+
This committee may simply consist of the Maintainer Council themselves. If this
110
+
responsibility is delegated, the Maintainers will appoint a team of at least two
111
+
contributors to handle it. The Maintainers will review who is assigned to this
112
+
at least once a year.
113
+
114
+
The Security Response Team is responsible for handling all reports of security
115
+
holes and breaches according to the [security policy](./SECURITY.md).
116
+
117
+
## Voting
118
+
119
+
While most business in Aya is conducted by "[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)",
120
+
periodically the Maintainers may need to vote on specific actions or changes.
121
+
A vote can be taken on the private developer Discord channel for security or conduct matters.
122
+
Any Maintainer may demand a vote be taken.
123
+
124
+
Most votes require a simple majority of all Maintainers to succeed, except where
125
+
otherwise noted. Two-thirds majority votes mean at least two-thirds of all
126
+
existing maintainers.
127
+
128
+
## Modifying this Charter
129
+
130
+
Changes to this Governance and its supporting documents may be approved by
No released versions of aya or it's subprojects will receive regular security updates until a mainline release has been performed.
6
+
A reported and fixed vulnerability will be included in the next minor release, which depending on the severity of the vulnerability may be immediate.
7
+
8
+
## Reporting a Vulnerability
9
+
10
+
To report a vulnerability, please use the [Private Vulnerability Reporting Feature](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability)
11
+
on GitHub. We will endevour to respond within 48hrs of reporting.
12
+
If a vulnerability is reported but considered low priority it may be converted into an issue and handled on the public issue tracker.
13
+
Should a vulnerability be considered severe we will endeavour to patch it within 48hrs of acceptance, and may ask for you to collaborate with us on a temporary private fork of the repository.
0 commit comments