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
Copy file name to clipboardExpand all lines: CODE_OF_CONDUCT.md
+14-14Lines changed: 14 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Contributor Covenant Code of Conduct
1
+
# Code of Conduct
2
2
3
3
## Our Pledge
4
4
@@ -10,19 +10,19 @@ We pledge to act and interact in ways that contribute to an open, welcoming, div
10
10
11
11
Examples of behavior that contributes to a positive environment for our community include:
12
12
13
-
* Demonstrating empathy and kindness toward other people
14
-
* Being respectful of differing opinions, viewpoints, and experiences
15
-
* Giving and gracefully accepting constructive feedback
16
-
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
17
-
* Focusing on what is best not just for us as individuals, but for the overall community
13
+
- Demonstrating empathy and kindness toward other people
14
+
- Being respectful of differing opinions, viewpoints, and experiences
15
+
- Giving and gracefully accepting constructive feedback
16
+
- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
17
+
- Focusing on what is best not just for us as individuals, but for the overall community
18
18
19
19
Examples of unacceptable behavior include:
20
20
21
-
* The use of sexualized language or imagery, and sexual attention or advances of any kind
22
-
* Trolling, insulting or derogatory comments, and personal or political attacks
23
-
* Public or private harassment
24
-
* Publishing others’ private information, such as a physical or email address, without their explicit permission
25
-
* Other conduct which could reasonably be considered inappropriate in a professional setting
21
+
- The use of sexualized language or imagery, and sexual attention or advances of any kind
22
+
- Trolling, insulting or derogatory comments, and personal or political attacks
23
+
- Public or private harassment
24
+
- Publishing others’ private information, such as a physical or email address, without their explicit permission
25
+
- Other conduct which could reasonably be considered inappropriate in a professional setting
26
26
27
27
## Enforcement Responsibilities
28
28
@@ -70,9 +70,9 @@ Community leaders will follow these Community Impact Guidelines in determining t
70
70
71
71
## Attribution
72
72
73
-
This Code of Conduct is adapted from the [Contributor Covenant][https://www.contributor-covenant.org], version 2.1,
74
-
available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).
73
+
This Code of Conduct is adapted from the <https://www.contributor-covenant.org>, version 2.1,
74
+
available at <https://www.contributor-covenant.org/version/2/1/code_of_conduct.html>.
75
75
76
76
Community Impact Guidelines were inspired by [Mozilla’s code of conduct enforcement ladder](https://github.com/mozilla/diversity).
77
77
78
-
For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are available at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations).
78
+
For answers to common questions about this code of conduct, see the FAQ at <https://www.contributor-covenant.org/faq>. Translations are available at <https://www.contributor-covenant.org/translations>.
Contributions to the framework, plugins, related tools and packages are welcome! Every little helps and credit will always be given.
4
-
5
-
As a contributor, here are the guidelines we would like you to follow:
3
+
Contributions to the framework, plugins, packages and related tools are welcome. As a contributor, here are the guidelines we would like you to follow:
6
4
7
5
-[Code of Conduct](#coc)
8
6
-[Question or Problem?](#question)
@@ -11,32 +9,30 @@ As a contributor, here are the guidelines we would like you to follow:
11
9
-[Submission Guidelines](#submit)
12
10
-[Coding Rules](#rules)
13
11
-[Commit Message Guidelines](#commit)
14
-
-[Development Guidelines](#dev)
15
12
16
13
## <aname="coc"></a> Code of Conduct
17
14
18
15
Please read and follow our [Code of Conduct][coc].
19
16
20
17
## <aname="question"></a> Question or Problem?
21
18
22
-
Use [Github Discussions][ghdiscussion]to ask support-related questions. This is because:
19
+
Please use [GitHub Discussions][ghdiscussion]for supportrelated questions and general discussions. Do NOT open issues as they are for bug reports and feature requests. This is because:
23
20
24
21
- Questions and answers stay available for public viewing so your question/answer might help someone else.
25
-
- Github Discussions voting system ensures the best answers are prominently visible.
26
-
27
-
Do not open issues for general support questions; they are used for bug reports and feature requests.
22
+
- GitHub Discussions voting system ensures the best answers are prominently visible.
28
23
29
24
## <aname="issue"></a> Found a Bug?
30
25
31
-
If you find a bug in the source code,[submit a bug report issue](#submit-issue) to our [GitHub repository][github].
26
+
If you find a bug in the source code [submit a bug report issue](#submit-issue).
32
27
Even better, you can [submit a Pull Request](#submit-pr) with a fix.
33
28
34
29
## <aname="feature"></a> Missing a Feature?
35
-
You can *request* a new feature by [submitting a feature request issue](#submit-issue) to our [GitHub repository][github].
30
+
31
+
You can *request* a new feature by [submitting a feature request issue](#submit-issue).
36
32
If you would like to *implement* a new feature:
37
33
38
-
* For a **Major Feature**, first open an issue and outline your proposal so that it can be discussed.
39
-
***Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
34
+
- For a **Major Feature**, first [open an issue](#submit-issue) and outline your proposal so that it can be discussed.
35
+
-**Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
40
36
41
37
## <aname="submit"></a> Submission Guidelines
42
38
@@ -46,28 +42,28 @@ Before you submit an issue, please search the [issue tracker][issues]. An issue
46
42
47
43
For bug reports, it is important that we can reproduce and confirm it. For this, we need you to provide a minimal reproduction instruction (this is part of the bug report issue template).
48
44
49
-
You can file new issues by selecting from our [new issue templates](https://github.com/fetchai/agents-aea/issues/new/choose) and filling out the issue template.
45
+
You can file new issues by selecting from our [new issue templates][new-issue] and filling out the issue template.
50
46
51
47
### <aname="submit-pr"></a> Submitting a Pull Request (PR)
52
48
53
49
Before you submit your Pull Request (PR) consider the following guidelines:
54
50
55
51
1. All Pull Requests should be based off of and opened against the `develop` branch. Do **not** open a Pull Request against `main`!
56
52
57
-
2. Search [Existing PRs](https://github.com/fetchai/agents-aea/pulls) for an open or closed PR that relates to your submission.
53
+
2. Search [Existing PRs][prs] for an open or closed PR that relates to your submission.
58
54
You don't want to duplicate existing efforts.
59
55
60
-
3. Be sure that an issue describes the problem you're fixing, or the design for the feature you'd like to add.
56
+
3. Be sure that an issue exists describing the problem you're fixing, or the design for the feature you'd like to add.
61
57
62
-
4.[Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the fetchai/agents-aea repo.
58
+
4.[Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the [repository][github].
63
59
64
60
5. In your forked repository, make your changes in a new git branch created from the `develop` branch.
65
61
66
-
6. Make your changes, **including appropriate test cases**.
62
+
6. Make your changes, **including test cases** and updating documentation where appropriate.
67
63
68
64
7. Follow our [coding rules](#rules).
69
65
70
-
8. Run all tests and checks locally, as described in the [development guide](#dev), and ensure they pass. This saves CI hours and ensures you only commit clean code.
66
+
8. Run all tests and checks locally, as described in the [development guide][developing], and ensure they pass. This saves CI hours and ensures you only commit clean code.
71
67
72
68
9. Commit your changes using a descriptive commit message that follows our [commit message conventions](#commit).
73
69
@@ -79,7 +75,7 @@ Before you submit your Pull Request (PR) consider the following guidelines:
79
75
80
76
#### Reviewing a Pull Request
81
77
82
-
The AEA team reserves the right not to accept pull requests from community members who haven't been good citizens of the community. Such behavior includes not following our [code of conduct][coc] and applies within or outside of the managed channels.
78
+
The AEA team reserves the right not to accept pull requests from community members who haven't been good citizens of the community. Such behavior includes not following our [code of conduct][coc] and applies within or outside the managed channels.
83
79
84
80
When you contribute a new feature, the maintenance burden is transferred to the core team. This means that the benefit of the contribution must be compared against the cost of maintaining the feature.
85
81
@@ -98,84 +94,32 @@ If we ask for changes via code reviews then:
98
94
After your pull request is merged, you can safely delete your branch and pull the changes from the (upstream) repository.
99
95
100
96
## <aname="rules"></a> Coding Rules
101
-
To ensure consistency throughout the source code, keep these rules in mind as you are working:
102
-
103
-
* All code must pass our code quality checks (linters, formatters, etc). See the [development guide](#dev) section for more detail.
104
-
* All features or bug fixes **must be tested** via unit-tests and if applicable integration-tests. These help to, a) prove that your code works correctly, and b) guard against future breaking changes and lower the maintenance cost.
105
-
* All public features **must be documented**.
106
-
* All files must include a license header.
107
-
108
-
## <aname="commit"></a> Commit Message Format
109
-
110
-
Please follow the [Conventional Commits v1.0.0][convcommit].
111
-
112
-
##### Types
113
-
114
-
The commit types (see [Conventional Commits v1.0.0][convcommit]) must be one of the following:
115
-
116
-
***build**: Changes that affect the build system or external dependencies
117
-
***ci**: Changes to our CI configuration files and scripts
118
-
***docs**: Documentation only changes
119
-
***feat**: A new feature
120
-
***fix**: A bug fix
121
-
***perf**: A code change that improves performance
122
-
***refactor**: A code change that neither fixes a bug nor adds a feature
123
-
***test**: Adding missing tests or correcting existing tests
124
-
125
-
## <aname="dev"></a> Development Guide
126
-
127
-
### To set up
128
-
129
-
First, set up your environment by either using the `develop-image` or by following these steps:
130
-
131
-
- Install Python (version `3.8`, `3.9` or `3.10`) and `poetry`. Then run:
132
-
133
-
make new-env
134
-
poetry shell
135
97
136
-
- The project uses [Google Protocol Buffers](https://developers.google.com/protocol-buffers/) compiler for message serialization. A guide on how to install it is found [here](https://fetchai.github.io/oef-sdk-python/user/install.html#protobuf-compiler).
137
-
138
-
### During development
139
-
140
-
We have various commands which are helpful during development.
141
-
142
-
- For linting and static analysis use:
143
-
144
-
make lint
145
-
make mypy
146
-
make pylint
147
-
make security
148
-
149
-
- For checking packages integrity:
150
-
151
-
make package-checks
152
-
153
-
- To run tests: `make test`.
154
-
155
-
- For testing `aea.{SUBMODULE}` with `tests/test_{TESTMODULE}` use:
156
-
157
-
make dir={SUBMODULE} tdir={TESTMODULE} test-sub
158
-
159
-
e.g.
160
-
161
-
make dir=cli tdir=cli test-sub
162
-
163
-
- When making changes to one of the `packages`, then use `python scripts/generate_ipfs_hashes.py` to generate the latest hashes.
164
-
165
-
#### Go Development
98
+
To ensure consistency throughout the source code, keep these rules in mind as you are working:
166
99
167
-
- The `fetchai/p2p_libp2p` package is partially developed in Go.
100
+
- All code must pass our code quality checks (linters, formatters, etc). See the [development guide][developing] section for more detail.
101
+
- All features or bug fixes **must be tested** via unit-tests and if applicable integration-tests. These help to, a. prove that your code works correctly, and b. guard against future breaking changes and lower the maintenance cost.
102
+
- All public features **must be documented**.
103
+
- All files must include a license header.
168
104
169
-
- To install Go visit the [Golang site](https://golang.org/doc/install).
105
+
## <aname="commit"></a> Commit Message Convention
170
106
171
-
- We use [`golines`](https://github.com/segmentio/golines) and [`golangci-lint`](https://golangci-lint.run) for linting.
107
+
Please follow the [Conventional Commits v1.0.0][convcommit]. The commit types must be one of the following:
172
108
173
-
- To run tests, use `go test -p 1 -timeout 0 -count 1 -v ./...` from the root directory of the package. If you experience installation or build issues run `go clean -modcache`.
109
+
-**build**: Changes that affect the build system or external dependencies
110
+
-**ci**: Changes to our CI configuration files and scripts
111
+
-**docs**: Documentation only changes
112
+
-**feat**: A new feature
113
+
-**fix**: A bug fix
114
+
-**nfunc**: Code that improves some non-functional characteristic, such as performance, security, ...
115
+
-**refactor**: A code change that neither fixes a bug nor adds a feature
116
+
-**test**: Adding missing tests or correcting existing tests
0 commit comments