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 <dave@dtucker.co.uk>
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.
Licensing is important to open source projects. It provides some assurances that
86
+
the software will continue to be available based under the terms that the
87
+
author(s) desired. We require that contributors sign off on commits submitted to
88
+
our project's repositories. The [Developer Certificate of Origin
89
+
(DCO)](https://probot.github.io/apps/dco/) is a way to certify that you wrote and
90
+
have the right to contribute the code you are submitting to the project.
91
+
92
+
You sign-off by adding the following to your commit messages. Your sign-off must
93
+
match the git user and email associated with the commit.
94
+
95
+
This is my commit message
96
+
97
+
Signed-off-by: Your Name <your.name@example.com>
98
+
99
+
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`
0 commit comments