Update PR template

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,20 +1,7 @@
 <!-- Empty or bad Descriptions are not welcome, Don't waste my time -->
 
-<!-- A Detailed Description -->
 ## Description
 
-<!-- A description of the tests performed to verify the changes -->
 ## Testing
 
-<!-- Please use Markdown Checkboxes. 
-[ ] = not done
-[x] = done
-(or just click checkboxes to toggle them)
--->
-## Checklist
-Things need to be done before this Pull Request can be merged.
-
-- [ ] Code is well-formatted and adheres to project style guidelines: `cargo fmt`
-- [ ] Code does not produce any clippy warnings: `cargo clippy`
-- [ ] All unit tests pass: `cargo test`
-- [ ] I added new unit tests, so other people don't accidentally break my code by changing other parts of the codebase. [How?](https://doc.rust-lang.org/book/ch11-01-writing-tests.html)
+Please follow our [Coding Guidelines](https://github.com/Pumpkin-MC/Pumpkin/blob/master/CONTRIBUTING.md#coding-guidelines)

CONTRIBUTING.md

@@ -29,16 +29,27 @@ There are several ways you can contribute to Pumpkin:
 
 The Documentation of Pumpkin can be found at <https://pumpkinmc.org/>
 
-**Tip: [typos](https://github.com/crate-ci/typos) is a great Project to detect and automatically fix typos
+**Tip: [typos](https://github.com/crate-ci/typos) is a great Project to detect and automatically fix typos**
 
 ### Coding Guidelines
 
+Things need to be done before this Pull Request can be merged. Your CI also checks most of them automaticly and fill fail if something is not fulfilled
+Note: Pumpkin's clippy settings are relativly strict, this can be may frustrating but is necesarry so the code says clean and conssistent
+**Basic**
+
+- **Code Formatting:** Code must be well-formatted and follow the project's style guidelines. You can achieve this by running `cargo fmt`.
+- **No Clippy Warnings:** Code should not produce any warnings from the Clippy linter. You can check for warnings using `cargo clippy --all-targets`.
+- **Passing Unit Tests:** All existing unit tests must pass successfully. You can run the tests with `cargo test`.
+
+**Best Pratice**
+
+- **Writing Unit Tests:** When adding new features or modifying existing code, consider adding unit tests to prevent regressions in the future. Refer to the Rust documentation for guidance on writing tests: https://doc.rust-lang.org/book/ch11-01-writing-tests.html
+- **Benchmarking:** If your changes might impact performance, consider adding benchmarks to track performance regressions or improvements. We use the Criterion library for benchmarking. Refer to their Quick Start guide for more information: https://github.com/bheisler/criterion.rs#quickstart
+- **Clear and Concise Commit Messages:** Use clear and concise commit messages that describe the changes you've made.
+- **Code Style:** Adhere to consistent coding style throughout your contributions.
+- **Documentation:** If your changes introduce new functionality, consider updating the relevant documentation.
 - **Working with Tokio and Rayon:**
-  When invoking CPU intensive work, this work should be done in the Rayon thread pool via `rayon::spawn`, Rayon's
-  parallel iterators, or otherwise instead of from the Tokio runtime. However, it is important that the
-  Tokio runtime not block on these Rayon calls. Instead, the data should be passed to the Tokio runtime
-  via async means, for example: `tokio::sync::mpsc`. An example of how to properly do this can be found
-  in `pumpkin_world::level::Level::fetch_chunks`.
+  When dealing with CPU-intensive tasks, it's recommended to utilize Rayon's thread pool (`rayon::spawn`), parallel iterators, or similar mechanisms instead of the Tokio runtime. However, it's crucial to avoid blocking the Tokio runtime on Rayon calls. Instead, use asynchronous methods like `tokio::sync::mpsc` to transfer data between the two runtimes. Refer to `pumpkin_world::level::Level::fetch_chunks` for an example of this approach.
 
 ### Additional Information