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
- Adds the Contributor Covenenat as our CoC
- Adds GOVERNANCE.md based on the CNCF template
- Updates CONTRIBUTING.md based on the CNCF template
- Adds MEETINGS.md to describe community meetings
- Adds MAINTAINERS.md to describe maintainers
- Adds REVIEWING.md basedon the CNCF template
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Welcome! We are glad that you want to contribute to our project! 💖
6
13
7
-
If you believe you've discovered a bug in bpfd, please check if the bug is
8
-
already known or [create an issue](https://github.com/bpfd-dev/bpfd/issues) on
9
-
github. Please also report an issue if you find documentation that you think is
10
-
confusing or could be improved.
14
+
As you get started, you are in the best position to give us feedback on areas of
15
+
our project that we need help with including:
11
16
12
-
When creating a new issue, make sure to include as many details as possible to
13
-
help us understand the problem. When reporting a bug, always specify which
14
-
version of bpfd you're using and which version of the linux kernel.
17
+
* Problems found during setting up a new developer environment
18
+
* Gaps in our Quickstart Guide or documentation
19
+
* Bugs in our automation scripts
15
20
16
-
## Fixing bugs and implementing new features
21
+
If anything doesn't make sense, or doesn't work when you run it, please open a
22
+
bug report and let us know!
17
23
18
-
Make sure that your work is tracked by an issue or a (draft) pull request, this
19
-
helps us avoid duplicating work.
24
+
## Ways to Contribute
20
25
21
-
### Commits
26
+
We welcome many different types of contributions including:
27
+
28
+
* New features
29
+
* Builds, CI/CD
30
+
* Bug fixes
31
+
* Documentation
32
+
* Issue Triage
33
+
* Answering questions on Slack/Mailing List
34
+
* Web design
35
+
* Communications / Social Media / Blog Posts
36
+
* Release management
37
+
38
+
Not everything happens through a GitHub pull request. Please come to our
39
+
[meetings](./MEETINGS.md) or [contact us](https://kubernetes.slack.com/archives/C04UJBW2553) and let's discuss how we can work
40
+
together.
41
+
42
+
### Come to Meetings
43
+
44
+
Absolutely everyone is welcome to come to any of our meetings. You never need an
45
+
invite to join us. In fact, we want you to join us, even if you don’t have
46
+
anything you feel like you want to contribute. Just being there is enough!
47
+
48
+
You can find out more about our meetings [here](./MEETINGS.md). You don’t have to turn on
49
+
your video. 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. [good first issue](https://github.com/bpfd-dev/bpfd/labels/good%20first%20issue) has extra information to
57
+
help you make your first contribution. [help wanted](https://github.com/bpfd-dev/bpfd/labels/help%20wanted) are issues
58
+
suitable for someone who isn't a core maintainer and is good to move onto after
59
+
your first pull request.
60
+
61
+
Sometimes there won’t be any issues with these labels. That’s ok! There is
62
+
likely still something for you to work on. If you want to contribute but you
63
+
don’t know where to start or can't find a suitable issue, you can reach out to us on Slack and we will be happy to help.
64
+
65
+
Once you see an issue that you'd like to work on, please post a comment saying
66
+
that you want to work on it. Something like "I want to work on this" is fine.
67
+
68
+
## Ask for Help
69
+
70
+
The best way to reach us with a question when contributing is to ask on:
71
+
72
+
* The original github issue
73
+
* Our Slack channel
74
+
75
+
## Pull Request Lifecycle
76
+
77
+
Pull requests are managed by Mergify.
78
+
79
+
Our process is currently as follows:
80
+
81
+
1. When you open a PR a maintainer will automatically be assigned for review
82
+
1. Make sure that your PR is passing CI - if you need help with failing checks please feel free to ask!
83
+
1. Once it is passing all CI checks, a maintainer will review your PR and you may be asked to make changes.
84
+
1. When you have received at least one approval from a maintainer, your PR will be merged automiatcally.
85
+
86
+
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
97
+
the software will continue to be available based under the terms that the
98
+
author(s) desired. We require that contributors sign off on commits submitted to
99
+
our project's repositories. The [Developer Certificate of Origin
100
+
(DCO)](https://probot.github.io/apps/dco/) is a way to certify that you wrote and
101
+
have the right to contribute the code you are submitting to the project.
102
+
103
+
You sign-off by adding the following to your commit messages. Your sign-off must
104
+
match the git user and email associated with the commit.
105
+
106
+
This is my commit message
107
+
108
+
Signed-off-by: Your Name <your.name@example.com>
109
+
110
+
Git has a `-s` command line option to do this automatically:
111
+
112
+
git commit -s -m 'This is my commit message'
113
+
114
+
If you forgot to do this and have not yet pushed your changes to the remote
115
+
repository, you can amend your commit with the sign-off by running
116
+
117
+
git commit --amend -s
118
+
119
+
## Logical Grouping of Commits
22
120
23
121
It is a recommended best practice to keep your changes as logically grouped as
24
122
possible within individual commits. If while you're developing you prefer doing
25
123
a number of commits that are "checkpoints" and don't represent a single logical
26
124
change, please squash those together before asking for a review.
125
+
When addressing review comments, please perform an interactive rebase and edit commits directly rather than adding new commits with messages like "Fix review comments".
27
126
28
-
####Commit message guidelines
127
+
## Commit message guidelines
29
128
30
129
A good commit message should describe what changed and why.
31
130
32
131
1. The first line should:
33
-
34
-
* contain a short description of the change (preferably 50 characters or less,
132
+
133
+
* contain a short description of the change (preferably 50 characters or less,
35
134
and no more than 72 characters)
36
-
* be entirely in lowercase with the exception of proper nouns, acronyms, and
135
+
* be entirely in lowercase with the exception of proper nouns, acronyms, and
37
136
the words that refer to code, like function/variable names
38
-
* be prefixed with the name of the sub crate being changed
137
+
* be prefixed with the name of the sub crate being changed
39
138
40
139
Examples:
41
140
42
-
* bpfd: validate program section names
43
-
* bpf: add dispatcher program test slot
141
+
* bpfd: validate program section names
142
+
* bpf: add dispatcher program test slot
44
143
45
144
2. Keep the second line blank.
46
145
3. Wrap all other lines at 72 columns (except for long URLs).
@@ -51,8 +150,8 @@ A good commit message should describe what changed and why.
51
150
52
151
Examples:
53
152
54
-
-`Fixes: #1337`
55
-
-`Refs: #1234`
153
+
*`Fixes: #1337`
154
+
*`Refs: #1234`
56
155
57
156
Sample complete commit message:
58
157
@@ -72,16 +171,15 @@ Fixes: #1337
72
171
Refs: #453, #154
73
172
```
74
173
75
-
## Testing Locally
174
+
## Pull Request Checklist
76
175
77
-
Please test your patches locally before they are tested using GitHub Actions.
176
+
When you submit your pull request, or you push new commits to it, our automated
177
+
systems will run some checks on your new code. We require that your pull request
178
+
passes these checks, but we also have more criteria than just that before we can
179
+
accept and merge it. We recommend that you check the following things locally
180
+
before you submit your code:
78
181
79
-
This can be accomplished by the following:
80
-
81
-
```sh
82
-
# we use nightly due to requiring some unstable features
83
-
cargo +nightly fmt
84
-
cargo +nightly clippy
85
-
cargo test
86
-
# if you have edited code in bpf, repeat in the above in that directory
87
-
```
182
+
* 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`
183
+
* That Go code has been formatted and linted
184
+
* That unit tests are passing locally with `cargo test`
0 commit comments