-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Home
tigercat2000 edited this page Jun 10, 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 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.
- 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 PR 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.
- 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 PR is to be put on hold until a consensus is achieved.
- The maintainers are responsible for properly tagging pull requests and issues.