Contributing
What a good pull request looks like here.
Altay takes contributions from anyone. The contributing guidelines are the authority; this page is the short version.
Before writing code
Open an issue first for anything non-trivial. A patch that solves a problem the maintainers are already fixing differently is wasted work, and finding that out after a week is worse than finding it out before.
For a first change, the easy task issues are scoped so you can learn the codebase without also designing something.
What gets merged
One change per pull request
A bug fix plus a refactor plus a formatting pass is three reviews pretending to be one.
Matching style
Follow the file you are editing rather than your own preferences.
No unrelated formatting
Reformatting a file you touched makes the diff unreadable and destroys blame history.
What breaks if you are wrong
The one thing a reviewer cannot work out from the diff. Put it in the description.
Vanilla behaviour
Vanilla behaviour needs evidence
A video, a packet capture, or a reference to how the client actually behaves. "It should work like this" is not enough: half the time the vanilla behaviour is stranger than the intuitive one.
Testing your change
composer install
php src/PocketMine.phpRun from source while iterating, and build a phar only when you want to test what users will get. See Building from source.
Reporting instead
Not every contribution is code. A bug report with a reproduction, a crash dump and the version it happened on is worth more than a patch that fixes the wrong thing. See Crashes and bug reports.