Skip to content

Commit 864c7df

Browse files
ReCore-sysReCore-sys
committed
Added CONTRIBUTING.md, CODE_OF_CONDUCT.md and a PR template
1 parent 89cca38 commit 864c7df

File tree

3 files changed

+211
-0
lines changed

3 files changed

+211
-0
lines changed

Diff for: ‎.github/PULL_REQUEST_TEMPLATE/template.md

+30
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
<!--- Provide a general summary of your changes in the Title above -->
2+
3+
## Description
4+
<!--- Describe your changes in detail -->
5+
6+
## Motivation and Context
7+
<!--- Why is this change required? What problem does it solve? -->
8+
<!--- If it fixes an open issue, please link to the issue here. -->
9+
10+
## How has this been tested?
11+
<!--- Please describe in detail how you tested your changes. -->
12+
<!--- Include details of your testing environment, tests ran to see how -->
13+
<!--- your change affects other areas of the code, etc. -->
14+
15+
## Screenshots (if appropriate):
16+
17+
## Types of changes
18+
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
19+
- [ ] Bug fix (non-breaking change which fixes an issue)
20+
- [ ] New feature (non-breaking change which adds functionality)
21+
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
22+
- [ ] Refactor (restructuring code, without changing its behavior)
23+
24+
## Checklist:
25+
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
26+
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
27+
- [ ] My code follows the code style of this project.
28+
- [ ] I have added tests to cover my changes.
29+
- [ ] All new and existing tests passed.
30+
- [ ] Clippy passes with no warnings.

Diff for: ‎CODE_OF_CONDUCT.md

+77
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,77 @@
1+
2+
# Contributor Covenant Code of Conduct
3+
4+
## Our Pledge
5+
6+
In the interest of fostering an open and welcoming environment, we as
7+
contributors and maintainers pledge to make participation in our project and
8+
our community a harassment-free experience for everyone, regardless of age, body
9+
size, disability, ethnicity, sex characteristics, gender identity and expression,
10+
level of experience, education, socio-economic status, nationality, personal
11+
appearance, race, religion, or sexual identity and orientation.
12+
13+
## Our Standards
14+
15+
Examples of behavior that contributes to creating a positive environment
16+
include:
17+
18+
* Using welcoming and inclusive language
19+
* Being respectful of differing viewpoints and experiences
20+
* Gracefully accepting constructive criticism
21+
* Focusing on what is best for the community
22+
* Showing empathy towards other community members
23+
24+
Examples of unacceptable behavior by participants include:
25+
26+
* The use of sexualized language or imagery and unwelcome sexual attention or
27+
advances
28+
* Trolling, insulting/derogatory comments, and personal or political attacks
29+
* Public or private harassment
30+
* Publishing others' private information, such as a physical or electronic
31+
address, without explicit permission
32+
* Other conduct which could reasonably be considered inappropriate in a
33+
professional setting
34+
35+
## Our Responsibilities
36+
37+
Project maintainers are responsible for clarifying the standards of acceptable
38+
behavior and are expected to take appropriate and fair corrective action in
39+
response to any instances of unacceptable behavior.
40+
41+
Project maintainers have the right and responsibility to remove, edit, or
42+
reject comments, commits, code, wiki edits, issues, and other contributions
43+
that are not aligned to this Code of Conduct, or to ban temporarily or
44+
permanently any contributor for other behaviors that they deem inappropriate,
45+
threatening, offensive, or harmful.
46+
47+
## Scope
48+
49+
This Code of Conduct applies within all project spaces, and it also applies when
50+
an individual is representing the project or its community in public spaces.
51+
Examples of representing a project or community include using an official
52+
project e-mail address, posting via an official social media account, or acting
53+
as an appointed representative at an online or offline event. Representation of
54+
a project may be further defined and clarified by project maintainers.
55+
56+
## Enforcement
57+
58+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
59+
reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
60+
complaints will be reviewed and investigated and will result in a response that
61+
is deemed necessary and appropriate to the circumstances. The project team is
62+
obligated to maintain confidentiality with regard to the reporter of an incident.
63+
Further details of specific enforcement policies may be posted separately.
64+
65+
Project maintainers who do not follow or enforce the Code of Conduct in good
66+
faith may face temporary or permanent repercussions as determined by other
67+
members of the project's leadership.
68+
69+
## Attribution
70+
71+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
72+
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
73+
74+
[homepage]: https://www.contributor-covenant.org
75+
76+
For answers to common questions about this code of conduct, see
77+
https://www.contributor-covenant.org/faq

Diff for: ‎CONTRIBUTING.md

+104
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
1+
# Contributing
2+
3+
When contributing to this repository, you'll have more luck with getting PRs approved if you come chat with us in the
4+
Discord server and letting us know about what you are fixing/adding.
5+
6+
## Pull Request Process
7+
8+
1. Make sure all tests and lints pass. PRs that don't pass CI will be rejected if your code is the cause of the failing
9+
tests/lints.
10+
2. Make sure all needed files are also included and not using absolute paths.
11+
3. Include a sufficient explanation of your PR. What is it adding/fixing, why does this feature need to be added/fixed,
12+
who have you discussed this with, etc. If these questions were answered in a conversation on this Discord, mention who
13+
you talked with and what consensus was reached. Unexplained PRs will rarely be accepted.
14+
4. Check again that tests pass.
15+
5. Check a 3rd time.
16+
6. Submit PR.
17+
18+
## Project specific guidelines
19+
Just some rules to try to keep the repo nice and organised
20+
### Branches
21+
#### `dev`
22+
This branch is the main branch. This is where all PRs should be made to. This branch is the most up to
23+
date and should only be merged into with completed features.
24+
#### `feature/feature-name`
25+
This branch is for developing a feature. Once the feature is complete, a PR should be
26+
made to the dev branch. This branch should be branched off of the dev branch.
27+
#### `fix/fixed-thing`
28+
This branch is for fixing a bug. Once the bug is fixed, a PR should be made to the dev
29+
branch. This branch should be branched off of the dev branch.
30+
#### `refactor/refactored-thing`
31+
This branch is for refactoring code. Once the code is refactored, a PR should be made to the dev branch.
32+
#### `housekeeping`
33+
This branch is for stuff relating to the repo itself. This could be updating the README, adding
34+
new CI checks, etc. This branch should be branched off of the dev branch.
35+
#### `docs`
36+
This branch is for updating the documentation. This branch should be branched off of the dev branch.
37+
This is used for stuff that doesn't actually modify the code, but the documentation.
38+
39+
### Project Layout
40+
```text
41+
+---.etc | Non-code files
42+
+---.github | GitHub specific files
43+
+---assets | Assets for the Readme
44+
+---src | Source code
45+
| +---bin | The main binary that stitches everything together
46+
| +---lib | The libraries that provide the business logic
47+
| | +---adapters | Adapters and parsers for data formats
48+
| | +---core | The core logic of the application
49+
| | +---derive_macros | Derive macros. Split into directories for each macro
50+
| | +---ecs | The ECS system
51+
| | +---events | The event system
52+
| | +---net | Networking code
53+
| | +---plugins | Plugins interface
54+
| | +---storage | Storage backend
55+
| | +---utils | Utility functions
56+
| | \---world | Code for interacting with the world
57+
| \---tests | Unit tests
58+
```
59+
If you add a new directory, please add it to the above list along with its purpose.
60+
61+
### Code rules
62+
1. Tests that only generate/dump data must be `#[ignore]`d. These tests are not useful for CI and should not be run.
63+
2. No absolute paths. This will break the CI and make it harder to run the code on different machines.
64+
3. Try to avoid just chaining `../` to get to the root of the project. This makes it harder to move files around and work
65+
out where a referenced file is. There is a `root!()` macro that can be used to get the root of the project as a string.
66+
4. Don't be lazy and use `unwrap()`. If you are sure that a value will always be `Some`, use `expect()`. If you are not
67+
sure, use `match` or `if let`.
68+
5. New dependencies should be added to the workspace `Cargo.toml` file. This will make it easier to manage dependencies
69+
and will make sure that all dependencies are of the same version.
70+
6. If you are adding a new feature that warrants major separation, add it as a new crate and then include it in the
71+
workspace `Cargo.toml` file. This will make it easier to manage the code and will make sure that the code is well
72+
separated.
73+
7. If you are adding an extra sub-crate, you must create a new set of `thiserror` based error types for that crate. This
74+
will make it easier to understand where an error is coming from and will make it easier to handle errors.
75+
8. Use `cargo clippy` to check for any issues with the code. This will be checked in CI and will cause the build to fail
76+
if there are any issues. There is no excuse for *your* code to fail the lints.
77+
9. Use `#[expect(lint)]` instead of `#[allow(lint)]` if you are sure that the lint is not an issue. This will make it
78+
easier to find and remove these lints in the future.
79+
10. Use `#[cfg(test)]` to only include code in tests. This will make the code easier to read and understand.
80+
11. Where applicable, add doc strings to functions and modules. This will make it easier for others to understand the code.
81+
Check https://doc.rust-lang.org/nightly/rustdoc/how-to-write-documentation.html for more information on how to write good
82+
documentation.
83+
12. Unsafe code is ok as long as it is well documented and the reason for the unsafe code is explained. If you are not sure
84+
if the code is safe, ask in the Discord.
85+
13. Limit the use of raw instructions as much as possible. This will make the code easier to read and understand. There
86+
are some cases where raw instructions are needed, but these should be kept to a minimum.
87+
14. You will be asked to fix your PR if folders like `.vscode` or `.idea` are included in the PR. These folders are
88+
specific to your IDE and should not be included in the PR.
89+
15. If you are adding a new feature, make sure to add tests for it. This will make sure that the feature works as expected
90+
and will help prevent regressions in the future.
91+
16. If you are fixing a bug, make sure to add a test that reproduces the bug. This will make sure that the bug is fixed
92+
and will help prevent regressions in the future.
93+
17. If your code isn't sufficiently documented, you will be asked to add documentation.
94+
18. If your code doesn't have tests where it should, you will be asked to add tests.
95+
96+
## Code of Conduct
97+
98+
Please note we have a code of conduct, please follow it in all your interactions with the project.
99+
100+
## License
101+
102+
By contributing, you agree that your contributions will be licensed under the project's license.
103+
104+
### [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)

0 commit comments

Comments
 (0)