docs: add actionable contribution guidelines

This commit is contained in:
Tropical 2026-03-09 20:23:04 -05:00
parent e4868446bd
commit d6b8d665df

View file

@ -1,4 +1,5 @@
# Contributing to 4JCraft
Thank you for considering contributing to 4JCraft! We appreciate all types of contributions, including bug fixes, new features, and documentation improvements.
Before you start contributing, please take a moment to review the guidelines outlined here. This ensures a smooth collaboration and helps maintain the project's quality.
@ -15,12 +16,52 @@ Make sure to follow the guidelines below when submitting code or issues.
## Submitting code
Simple rules for publishing code:
- Do not publish AI-generated or LLM generated code
- Publish your new code in a new branch
- Join our Discord server to ping us (the lead developers) about your pull requests
- Keep your code clean and readable.
- Use conventional commits (this is not required)
Make sure your code compiles before making a pull request! and make sure that it's readable
If you are submitting a pull request to this repository, here are some guidelines to keep in mind.
Remember ALL your changes will be licensed under GNU General Public License V3.0.
### Test your changes.
Please run the game and make sure your code runs as expected before marking a pull request ready for review.
### Keep scope to a minimum.
Pull requests should ideally do one thing in one place. Avoiding opening massive pull requests that change multiple components of the game. These are often not reviewable and result in unmanageable conflicts with other active PRs.
### Use common sense with commits.
Commit names should clearly describe what was changed in the commit. [Conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) are generally appreciated, but by no means required. Similar to pull requests, commits should ideally be limited in scope and easy to track over time.
### Keep code clean and readable.
At this time, we do not have a style guide or rules for how code should be formatted. In general, code should be readable and try to match the styling and conventions of whatever is around it.
### Avoid changing in-game behavior.
At this time, we are trying to stay as close to the vanilla game as close as possible. Anything that changes game behavior in breaking ways will likely be closed. This includes adding new features or backporting newer functionality from other (non-LCE) versions of the game.
> Some exceptions to this guideline apply. Features required for platform porting (such as adding new input methods) are considered in-scope. In some cases, temporary "stop-gap" implementations or additional functionality may be accepted on a case-by-case basis, provided it is clearly documented and possible to disable through a compiler flag.
### Bugfixes should be clearly commented.
If you are submitting a bugfix or a minor addition to *game-relevant code*, clearly comment the purpose of this fix in a comment starting with `// 4jcraft:`. This indicates a patch over the original game code and lets us keep track of what has been modified in case it needs to be reverted later.
> **Example:**
>
> ```cpp
> // 4jcraft: masking the id to 11 bits before writing to account for entity ids > 4095.
> // This fixes a connection drop when loading the tutorial world on linux.
> //
> // FIXME: find the root cause of this, since there shouldn't be more than 4095 entities.
> dos->writeShort((id & 0x07FF) | 0x800);
> ```
### Try to fix the cause, not the effect.
If you are fixing a bug, avoid submitting "hacks" that attempt to patch the effects of the bug rather than the root cause.
> Exceptions to this rule may apply depending on the severity of the bug, provided that the code is clearly commented as a hack with a relevant `// 4jcraft:` comment.
### Don't submit code written by AI.
Submitting code to this repository authored by generative AI tools (LLMs, agentic coding tools, etc...) is strictly forbidden. Pull requests that are clearly vibe-coded or written by an LLM will be closed.
> **Rationale:** Contributors are expected to both fully understand the code that they write **and** have the necessary skills to *maintain it*. Opening PRs containing code that you did not write yourself more often than not fails to meet either of these expectations, therefore it is disallowed.