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.
26
+
We welcome many different types of contributions including:
26
27
27
-
## Fixing bugs and implementing new features
28
+
* New features
29
+
* Builds, CI/CD
30
+
* Bug fixes
31
+
* Documentation
32
+
* Issue Triage
33
+
* Answering questions on Discord
34
+
* Web design
35
+
* Communications / Social Media / Blog Posts
36
+
* Release management
28
37
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.
38
+
Not everything happens through a GitHub pull request. Please come to our
39
+
[Discord](https://discord.gg/xHW2cb2N6G) and let's discuss how we can work
40
+
together.
32
41
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.
42
+
## Find an Issue
35
43
36
-
### Commits
44
+
We have good first issues for new contributors and help wanted issues suitable
45
+
for any contributor. [good first issue](https://github.com/aya-rs/aya/labels/good%20first%20issue) has extra information to
46
+
help you make your first contribution. [help wanted](https://github.com/aya-rs/aya/labels/help%20wanted) are issues
47
+
suitable for someone who isn't a core maintainer and is good to move onto after
48
+
your first pull request.
49
+
50
+
Sometimes there won’t be any issues with these labels. That’s ok! There is
51
+
likely still something for you to work on. If you want to contribute but you
52
+
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.
53
+
54
+
Once you see an issue that you'd like to work on, please post a comment saying
55
+
that you want to work on it. Something like "I want to work on this" is fine.
56
+
57
+
## Ask for Help
58
+
59
+
The best way to reach us with a question when contributing is to ask on:
60
+
61
+
* The original github issue
62
+
* Our Discord
63
+
64
+
## Pull Request Lifecycle
65
+
66
+
Pull requests are managed by Mergify.
67
+
68
+
Our process is currently as follows:
69
+
70
+
1. When you open a PR a maintainer will automatically be assigned for review
71
+
1. Make sure that your PR is passing CI - if you need help with failing checks please feel free to ask!
72
+
1. Once it is passing all CI checks, a maintainer will review your PR and you may be asked to make changes.
73
+
1. When you have received at two approving reviews from a maintainer, your PR will be merged automiatcally.
74
+
75
+
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.
Git has a `-s` command line option to do this automatically:
100
+
101
+
git commit -s -m 'This is my commit message'
102
+
103
+
If you forgot to do this and have not yet pushed your changes to the remote
104
+
repository, you can amend your commit with the sign-off by running
105
+
106
+
git commit --amend -s
107
+
108
+
## Logical Grouping of Commits
37
109
38
110
It is a recommended best practice to keep your changes as logically grouped as
39
111
possible within individual commits. If while you're developing you prefer doing
40
112
a number of commits that are "checkpoints" and don't represent a single logical
41
113
change, please squash those together before asking for a review.
114
+
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
115
43
-
####Commit message guidelines
116
+
## Commit message guidelines
44
117
45
118
A good commit message should describe what changed and why.
46
119
47
120
1. The first line should:
48
-
49
-
* contain a short description of the change (preferably 50 characters or less,
121
+
122
+
* contain a short description of the change (preferably 50 characters or less,
50
123
and no more than 72 characters)
51
-
* be entirely in lowercase with the exception of proper nouns, acronyms, and
124
+
* be entirely in lowercase with the exception of proper nouns, acronyms, and
52
125
the words that refer to code, like function/variable names
53
-
* be prefixed with the name of the sub crate being changed
126
+
* be prefixed with the name of the sub crate being changed
54
127
55
128
Examples:
56
129
57
-
* aya: handle reordered functions
58
-
* aya-bpf: SkSkbContext: add ::l3_csum_replace
130
+
* bpfd: validate program section names
131
+
*bpf: add dispatcher program test slot
59
132
60
133
2. Keep the second line blank.
61
134
3. Wrap all other lines at 72 columns (except for long URLs).
@@ -66,8 +139,8 @@ A good commit message should describe what changed and why.
66
139
67
140
Examples:
68
141
69
-
-`Fixes: #1337`
70
-
-`Refs: #1234`
142
+
*`Fixes: #1337`
143
+
*`Refs: #1234`
71
144
72
145
Sample complete commit message:
73
146
@@ -86,3 +159,16 @@ nicely even when it is indented.
86
159
Fixes: #1337
87
160
Refs: #453, #154
88
161
```
162
+
163
+
## Pull Request Checklist
164
+
165
+
When you submit your pull request, or you push new commits to it, our automated
166
+
systems will run some checks on your new code. We require that your pull request
167
+
passes these checks, but we also have more criteria than just that before we can
168
+
accept and merge it. We recommend that you check the following things locally
169
+
before you submit your code:
170
+
171
+
* 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`
172
+
* That Go code has been formatted and linted
173
+
* That unit tests are passing locally with `cargo test`
174
+
* 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