-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Home
Mark van Alphen edited this page Feb 12, 2015
·
20 revisions
- 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 Requests. 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.
- Do not push directly to the repo, always make a pull request.
- Your pull requests should be atomic. Balance changes, Bug Fixes, New features should all be in separate PRs.
- 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.
- The maintainers are responsible for properly tagging PRs.
- Please document and explain your PRs 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 PR is about.
- Make sure to use the mapmerge tools on all map edits to our primary map. PRs that contain edits that don't use the mapmerge tool will be automatically denied, unless explicit permission was given.
- Do not self-merge. A different maintainer needs to review your PR, no matter how trivial. This is to ensure quality.
- Bugfix PRs can be merged as soon as reviewed.
- The shortest waiting period for -any- feature or balance altering PR 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 PR is to be put on hold until a consensus is achieved.