Home

Instructions on using the Paradise Github

Instructions for players

• Bug reports should be as detailed as possible, including instructions on how to reproduce the bug.
• If you comment on an active pull request, make sure your comment is concise and to the point. No single-word 'lol' comments please.
• Players are welcome to participate in the development of this fork and submit their own pull request. If the work you are submitting is new features or affects balance, it is strongly recommended you get approval/traction for it from our forums before starting the actual coding.

Instructions for coders

• Do not push directly to the repository, always make a pull request.
• Your pull requests should be atomic. Balance changes, bug fixes and new features should all be in separate pull requests.
• Your commits should be atomic. Make one commit for each distinct change, so if a part of a PR need to be removed/change, you can simply modify that single commit.
• Please document and explain your pull requests thoroughly. What each commit changes and why. We do not want to have to read all of your commit names to figure out what your pull request is about.
• Make sure to use the mapmerge tools on all map edits to the primary map files. Pull requests that contain edits that don't use the mapmerge tool will be automatically denied, unless explicit permission was given.
• Any pull request that is not solely composed of fixes or non gameplay-affecting refactors must have a changelog. See here for further instructions, and here for an example changelog. Alternatively, inline changelogs are supported through the format descriped here.
• Any type and proc paths MUST use absolute pathing unless the file you are working in primarily utilizes relative pathing.
• PRs should not have any merge commits except in the case of fixing merge conflicts for an existing PR. Use git rebase or git reset to update your branches, not git pull.

Instructions for maintainers

• Do not self-merge. A different maintainer needs to review your pull request, no matter how trivial. This is to ensure quality.
• Wait for the Travis build to complete. If it fails, the pull request may only be merged if there's a good reason.
• Bugfix and refactor pull requests can be merged as soon as reviewed.
• The shortest waiting period for -any- feature or balance altering pull request is 24 hours, to allow other coders and the community time to discuss the proposed changes.
• If the discussion is active or the change is controversial, the pull request is to be put on hold until a consensus is achieved.
• The maintainers are responsible for properly tagging pull requests and issues.