Merge branch 'rewrite/housekeeping' into rewrite/v3

[skip CI]

.github/PULL_REQUEST_TEMPLATE/template.md

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

.github/workflows/rust.yml

@@ -34,13 +34,6 @@ jobs:
         uses: dtolnay/rust-toolchain@nightly
         with:
           targets: ${{ matrix.target }}
-
-      - name: Run Clippy
-        uses: ClementTsang/[email protected]
-        with:
-          args: -- -Dwarnings
-          command: clippy
-
       - name: Build
         uses: ClementTsang/[email protected]
         with:
@@ -58,3 +51,11 @@ jobs:
         with:
           name: ferrumc-${{ matrix.os }}
           path: target/${{ matrix.target }}/release/ferrumc*
+  check:
+    steps:
+      - name: Run Clippy
+        uses: ClementTsang/[email protected]
+        with:
+          args: -- -Dwarnings
+          command: clippy
+

CODE_OF_CONDUCT.md

@@ -0,0 +1,77 @@
+
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when
+an individual is representing the project or its community in public spaces.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event. Representation of
+a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,104 @@
+# Contributing
+
+When contributing to this repository, you'll have more luck with getting PRs approved if you come chat with us in the
+Discord server and letting us know about what you are fixing/adding.
+
+## Pull Request Process
+
+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
+tests/lints.
+2. Make sure all needed files are also included and not using absolute paths.
+3. Include a sufficient explanation of your PR. What is it adding/fixing, why does this feature need to be added/fixed,
+who have you discussed this with, etc. If these questions were answered in a conversation on this Discord, mention who
+you talked with and what consensus was reached. Unexplained PRs will rarely be accepted.
+4. Check again that tests pass.
+5. Check a 3rd time.
+6. Submit PR.
+
+## Project specific guidelines
+Just some rules to try to keep the repo nice and organised
+### Branches
+#### `dev`
+This branch is the main branch. This is where all PRs should be made to. This branch is the most up to
+date and should only be merged into with completed features.
+#### `feature/feature-name`
+This branch is for developing a feature. Once the feature is complete, a PR should be
+made to the dev branch. This branch should be branched off of the dev branch.
+#### `fix/fixed-thing`
+This branch is for fixing a bug. Once the bug is fixed, a PR should be made to the dev
+branch. This branch should be branched off of the dev branch.
+#### `refactor/refactored-thing`
+This branch is for refactoring code. Once the code is refactored, a PR should be made to the dev branch.
+#### `housekeeping`
+This branch is for stuff relating to the repo itself. This could be updating the README, adding
+new CI checks, etc. This branch should be branched off of the dev branch.
+#### `docs`
+This branch is for updating the documentation. This branch should be branched off of the dev branch.
+This is used for stuff that doesn't actually modify the code, but the documentation.
+
+### Project Layout
+```text
++---.etc                    | Non-code files
++---.github                 | GitHub specific files
++---assets                  | Assets for the Readme
++---src                     | Source code
+|   +---bin                 | The main binary that stitches everything together
+|   +---lib                 | The libraries that provide the business logic
+|   |   +---adapters        | Adapters and parsers for data formats
+|   |   +---core            | The core logic of the application
+|   |   +---derive_macros   | Derive macros. Split into directories for each macro
+|   |   +---ecs             | The ECS system
+|   |   +---events          | The event system
+|   |   +---net             | Networking code
+|   |   +---plugins         | Plugins interface
+|   |   +---storage         | Storage backend
+|   |   +---utils           | Utility functions
+|   |   \---world           | Code for interacting with the world
+|   \---tests               | Unit tests
+```
+If you add a new directory, please add it to the above list along with its purpose.
+
+### Code rules
+1. Tests that only generate/dump data must be `#[ignore]`d. These tests are not useful for CI and should not be run.
+2. No absolute paths. This will break the CI and make it harder to run the code on different machines.
+3. Try to avoid just chaining `../` to get to the root of the project. This makes it harder to move files around and work
+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.
+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
+sure, use `match` or `if let`.
+5. New dependencies should be added to the workspace `Cargo.toml` file. This will make it easier to manage dependencies
+and will make sure that all dependencies are of the same version.
+6. If you are adding a new feature that warrants major separation, add it as a new crate and then include it in the
+workspace `Cargo.toml` file. This will make it easier to manage the code and will make sure that the code is well
+separated.
+7. If you are adding an extra sub-crate, you must create a new set of `thiserror` based error types for that crate. This
+will make it easier to understand where an error is coming from and will make it easier to handle errors.
+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
+if there are any issues. There is no excuse for *your* code to fail the lints.
+9. Use `#[expect(lint)]` instead of `#[allow(lint)]` if you are sure that the lint is not an issue. This will make it
+easier to find and remove these lints in the future.
+10. Use `#[cfg(test)]` to only include code in tests. This will make the code easier to read and understand.
+11. Where applicable, add doc strings to functions and modules. This will make it easier for others to understand the code.
+Check https://doc.rust-lang.org/nightly/rustdoc/how-to-write-documentation.html for more information on how to write good
+documentation.
+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
+if the code is safe, ask in the Discord.
+13. Limit the use of raw instructions as much as possible. This will make the code easier to read and understand. There
+are some cases where raw instructions are needed, but these should be kept to a minimum.
+14. You will be asked to fix your PR if folders like `.vscode` or `.idea` are included in the PR. These folders are
+specific to your IDE and should not be included in the PR.
+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
+and will help prevent regressions in the future.
+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
+and will help prevent regressions in the future.
+17. If your code isn't sufficiently documented, you will be asked to add documentation.
+18. If your code doesn't have tests where it should, you will be asked to add tests.
+
+## Code of Conduct
+
+Please note we have a code of conduct, please follow it in all your interactions with the project.
+
+## License
+
+By contributing, you agree that your contributions will be licensed under the project's license.
+
+### [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)