From 0676439088d48fde151db4d497df6b0268d38e94 Mon Sep 17 00:00:00 2001 From: BoySanic Date: Wed, 12 Nov 2025 17:45:39 -0800 Subject: [PATCH 1/8] Add PR template --- .github/pull_request_template.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 .github/pull_request_template.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000000..d3ba758612 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,23 @@ +## What does this PR change? + +## If not already covered by an issue (specified below), what is the motivation for the change(s) in this PR? + +## Fixes: (issue number here) + +## What design decisions did you make to develop your solution ? Why did you make those choices? + - If this change required refactoring existing code, explain why it needed to be refactored. What limitation are you resolving with the refactor? + +## If this change is something the users will notice, please write a one-sentence description of this change so it may be used in a changelog: + +## Checklist before submitting the PR: +- [ ] Please read the contributing guidelines document and ensure your changes are in compliance with those guidelines. +- [ ] Are there any open pull requests that resolve the same issue? If so, mention them in this PR. Multiple approaches are welcomed as the one that is liked most will be selected. +- [ ] Please run the cubyz formatter on your changes to ensure formatting consistency + - The CI will catch this if you don't +- [ ] Make sure your PR is named appropriately to describe the change briefly. No "fix #12345" etc, please. +- [ ] Did you remove an old item/block/biome/etc? Please add a migration in the appropriate `_migrations.zig.zon` to smoothly migrate existing worldsto your new change. +- [ ] Have you tested your change? + - [ ] Make sure the game opens and you can join a world + - [ ] Analyze your change and determine which features it impacts. Make sure your change does not cause those features to break. + - [ ] Did you modify or add any static functions? (i.e. data in -> data out, no out-of-scope variables touched) If so, please write a test for those functions you've changed/added. + From 8328dab7c136ab871c3113a200f0b29e728bf1a9 Mon Sep 17 00:00:00 2001 From: BoySanic Date: Wed, 12 Nov 2025 17:48:03 -0800 Subject: [PATCH 2/8] Modify PR template --- .github/pull_request_template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index d3ba758612..03f0c84ca2 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -5,7 +5,7 @@ ## Fixes: (issue number here) ## What design decisions did you make to develop your solution ? Why did you make those choices? - - If this change required refactoring existing code, explain why it needed to be refactored. What limitation are you resolving with the refactor? + - If this change required refactoring existing code, explain why it needed to be refactored. What limitation are you resolving with the refactor? ## If this change is something the users will notice, please write a one-sentence description of this change so it may be used in a changelog: From 39511c5cd3bbb85a68837c2a4f0610f5a4e9a63a Mon Sep 17 00:00:00 2001 From: BoySanic Date: Wed, 12 Nov 2025 17:48:50 -0800 Subject: [PATCH 3/8] modify pr template --- .github/pull_request_template.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 03f0c84ca2..d686accb43 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -5,7 +5,8 @@ ## Fixes: (issue number here) ## What design decisions did you make to develop your solution ? Why did you make those choices? - - If this change required refactoring existing code, explain why it needed to be refactored. What limitation are you resolving with the refactor? +If this change required refactoring existing code, explain why it needed to be refactored. +What limitation are you resolving with the refactor? ## If this change is something the users will notice, please write a one-sentence description of this change so it may be used in a changelog: From 63f0e2aeaf950698587f4b5b7ebdf2f1b599d2f4 Mon Sep 17 00:00:00 2001 From: BoySanic Date: Wed, 12 Nov 2025 17:52:07 -0800 Subject: [PATCH 4/8] modify template --- .github/pull_request_template.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index d686accb43..8fc5e5c94b 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -2,11 +2,13 @@ ## If not already covered by an issue (specified below), what is the motivation for the change(s) in this PR? -## Fixes: (issue number here) +## What issues does this PR resolve? (Add as many as are applicable) +### Example: Fixes #12345 +- Fixes # +- Fixes # ## What design decisions did you make to develop your solution ? Why did you make those choices? -If this change required refactoring existing code, explain why it needed to be refactored. -What limitation are you resolving with the refactor? + - If this change required refactoring existing code, explain why it needed to be refactored. What limitation are you resolving with the refactor? ## If this change is something the users will notice, please write a one-sentence description of this change so it may be used in a changelog: From e8a641c534eed11656162957460bbd17f8814621 Mon Sep 17 00:00:00 2001 From: BoySanic Date: Wed, 12 Nov 2025 21:38:36 -0800 Subject: [PATCH 5/8] Adjust --- .github/pull_request_template.md | 29 +++++++---------------------- 1 file changed, 7 insertions(+), 22 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 8fc5e5c94b..f0de1ff1ae 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,26 +1,11 @@ -## What does this PR change? +## Description -## If not already covered by an issue (specified below), what is the motivation for the change(s) in this PR? +## Approach -## What issues does this PR resolve? (Add as many as are applicable) -### Example: Fixes #12345 -- Fixes # -- Fixes # - -## What design decisions did you make to develop your solution ? Why did you make those choices? - - If this change required refactoring existing code, explain why it needed to be refactored. What limitation are you resolving with the refactor? - -## If this change is something the users will notice, please write a one-sentence description of this change so it may be used in a changelog: +## Motivation ## Checklist before submitting the PR: -- [ ] Please read the contributing guidelines document and ensure your changes are in compliance with those guidelines. -- [ ] Are there any open pull requests that resolve the same issue? If so, mention them in this PR. Multiple approaches are welcomed as the one that is liked most will be selected. -- [ ] Please run the cubyz formatter on your changes to ensure formatting consistency - - The CI will catch this if you don't -- [ ] Make sure your PR is named appropriately to describe the change briefly. No "fix #12345" etc, please. -- [ ] Did you remove an old item/block/biome/etc? Please add a migration in the appropriate `_migrations.zig.zon` to smoothly migrate existing worldsto your new change. -- [ ] Have you tested your change? - - [ ] Make sure the game opens and you can join a world - - [ ] Analyze your change and determine which features it impacts. Make sure your change does not cause those features to break. - - [ ] Did you modify or add any static functions? (i.e. data in -> data out, no out-of-scope variables touched) If so, please write a test for those functions you've changed/added. - +- [ ] I've read and followed the [contribution guidelines](https://github.com/PixelGuys/Cubyz/blob/master/docs/CONTRIBUTING.md). +- [ ] I've tested my change thoroughly to ensure I've introduced no regressions. +- [ ] I've added tests where appropriate. +- [ ] I've linked the related issue to this PR either with a "Fixes #12345" or via the github web interface. From 3d5f59cc4bc5acb7f79714ab75c3e02dc6d4d6ad Mon Sep 17 00:00:00 2001 From: BoySanic Date: Thu, 13 Nov 2025 12:27:57 -0800 Subject: [PATCH 6/8] Contributing update --- docs/CONTRIBUTING.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 0111e4d7cb..ae438c3a05 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -92,6 +92,17 @@ Often the simplest code is easier to read, easier to maintain and more efficient - Use the simplest data structure for the job: e.g. use a slice instead of List if you know the size upfront - Don't make things public if they don't need to be +## Test your changes + +Before you submit changes for review, you should take some time to test your changes. +- Be mindful of the features you have touched by changing the code you've changed. Test those features to ensure there were no regressions. +- We don't expect you to know everything here. But, a little work up front can save review cycles in the future if you may have broken something by mistake. + +## Name your PR appropriately + +For example, if you're fixing issue #12345, don't name the PR "Fix #12345". +Instead, include that in the description of the PR and name your PR something that better describes the impact of your change (i.e. "Add ", "Rebalance tool properties", "Refactor ", etc) + ## A note on performance optimizations I like to follow Casey Muratori's optimization philosophy as outlined here: https://www.youtube.com/watch?v=pgoetgxecw8 From 44a703cc71a073f98fa27e0f520278411ecb3e2a Mon Sep 17 00:00:00 2001 From: BoySanic Date: Fri, 14 Nov 2025 08:47:22 -0800 Subject: [PATCH 7/8] Adjustments --- .github/pull_request_template.md | 8 ++++---- docs/CONTRIBUTING.md | 33 ++++++++++++++++++-------------- 2 files changed, 23 insertions(+), 18 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index f0de1ff1ae..bc01089647 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,10 +1,10 @@ -## Description +# Description -## Approach +# Motivation -## Motivation +# Approach -## Checklist before submitting the PR: +# Checklist before submitting the PR: - [ ] I've read and followed the [contribution guidelines](https://github.com/PixelGuys/Cubyz/blob/master/docs/CONTRIBUTING.md). - [ ] I've tested my change thoroughly to ensure I've introduced no regressions. - [ ] I've added tests where appropriate. diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index ae438c3a05..f48be72513 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -45,7 +45,7 @@ To have more success it would help to split things up into smaller PRs, maybe st This saves time on your end spent reworking your large pull request 10 times. And reviewing your large pull request 10 times is also not fun. -# Write correct, readable and maintainable code +#Write correct, readable and maintainable code ## Explicitly handle all errors @@ -92,17 +92,6 @@ Often the simplest code is easier to read, easier to maintain and more efficient - Use the simplest data structure for the job: e.g. use a slice instead of List if you know the size upfront - Don't make things public if they don't need to be -## Test your changes - -Before you submit changes for review, you should take some time to test your changes. -- Be mindful of the features you have touched by changing the code you've changed. Test those features to ensure there were no regressions. -- We don't expect you to know everything here. But, a little work up front can save review cycles in the future if you may have broken something by mistake. - -## Name your PR appropriately - -For example, if you're fixing issue #12345, don't name the PR "Fix #12345". -Instead, include that in the description of the PR and name your PR something that better describes the impact of your change (i.e. "Add ", "Rebalance tool properties", "Refactor ", etc) - ## A note on performance optimizations I like to follow Casey Muratori's optimization philosophy as outlined here: https://www.youtube.com/watch?v=pgoetgxecw8 @@ -143,7 +132,9 @@ There are a few more things not covered by the formatter: assignment ops < bool ops < compare ops < bitwise ops < shift ops < add/sub < mul/div < unary ops
Only add parenthesis if you need them. Precedence on the right side of the spectrum (unary and mul/div/mod) is also shown visually (enforced by the formatter) through spacing: `x = -a + b*c` instead of `x = - a + b * c` -# Don't put multiple changes into one pull request +# Pull requests: + +## Don't put multiple changes into one pull request This includes introduction of non-trivial helper functions, refactoring existing code. @@ -159,7 +150,21 @@ And even if it doesn't happen, now the same code has to be reviewed again in it' If instead you make 3 separate PRs, the first two can be merged on the same day, while the last one needs to be edited. The chances of a merge conflict are small, since 2/3 changes are already merged. And code review is also easier, since only the broken code has to be reviewed more than once. -# Check the changes after creating your pull request +## Test your changes + +Before you submit changes for review, you should take some time to test your changes. +- Be mindful of the features you have touched by changing the code you've changed. Test those features to ensure there were no regressions. +- We don't expect you to know everything here. But, a little work up front can save review cycles in the future if you may have broken something by mistake. + +## Correct code should not produce error logs +- Resolve any error logs that appear as a consequence of your change. This can mean some other code is responsible for the error and it was only uncovered by your change. In which case, see above regarding multiple changes in one pull request. + +## Name your PR appropriately + +Don't name the PR "Fix [#12345](https://github.com/PixelGuys/Cubyz/issues/)". +Instead, include that in the description of the PR and name your PR something that better describes the impact of your change (i.e. "Add ", "Rebalance tool properties", "Refactor ", etc) + +## Check the changes after creating your pull request With a quick check you can ensure that you didn't add any unintended changes. From ee885e0441ea9123300556d8251b13c7399ff5ca Mon Sep 17 00:00:00 2001 From: BoySanic Date: Fri, 14 Nov 2025 08:49:29 -0800 Subject: [PATCH 8/8] Add link to docs --- .github/pull_request_template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index bc01089647..eb50bb7653 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -8,4 +8,4 @@ - [ ] I've read and followed the [contribution guidelines](https://github.com/PixelGuys/Cubyz/blob/master/docs/CONTRIBUTING.md). - [ ] I've tested my change thoroughly to ensure I've introduced no regressions. - [ ] I've added tests where appropriate. -- [ ] I've linked the related issue to this PR either with a "Fixes #12345" or via the github web interface. +- [ ] I've linked the related issue to this PR either with a "Fixes #12345" or via the github web interface. [Tutorial](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue)