Contributing - Podshot/MCEdit-Unified GitHub Wiki

Go here for more on Contributing to MCEdit.

Note: MCEdit-Unified is the same program (with updates) so no License/s or Laws were broken as of the creation date of MCEdit-Unifed.

MCEdit is an open-source project. We ask that all contributions be licensed under the permissive ISC license:

Copyright (c)2012

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

A compatible license such as the MIT or the new BSD license is acceptable, but we prefer they only be used when including code already written by third parties. Use the ISC license above when writing new code for MCEdit.

Before hacking away at the code, you should open a new issue to discuss the changes you want to make. It's possible that the work you want to do is already being done by someone else or is otherwise redundant, or that the feature you want to add doesn't fit with the project's goals.

If you're making a few changes for your own personal use, you can go ahead and send a pull request without opening an issue first. Even if it's not eventually accepted into master, others will be able to try out your changes and give you feedback on them.

Do your best to follow pep8. Install the pep8 and autopep8 tools using pip/easy_install to check or automatically fix up your code before you commit. It is also suggested to use pylint and/or pychecker or the code-checking features of programs like Eclipse or PyCharm to check for certain mistakes.

All changes should be sent via GitHub pull request so we can add comments and discuss the changes line by line.

I suggest setting up your local git repo as described in https://help.github.com/articles/fork-a-repo; be sure to add an upstream remote so you can pull changes from the main mcedit/mcedit repo.

Instead of working on master, create a new branch and commit your changes onto it. This way your master branch can track the upstream branch at mcedit/mcedit/master.

Don't merge mcedit/mcedit/master into your working branch. Instead, use git fetch upstream to grab the latest master from upstream and then git rebase my-branch-name upstream/master to move your branch onto the end of master. Using rebase has two advantages: One, there are no merge commits that go back and forth (i.e. Merge branch master from mcedit/mcedit followed by Merge branch my-branch-name from some-git-user/mcedit) and Two, the merge commit has no changes itself (like those that result from resolving merge conflicts) because those changes get "folded" into the branch`s commits during the rebase.

If any merge conflicts occur during a rebase, the rebase will pause at the offending commit so you can resolve any merge conflicts and re-commit the results. (Rebase is rewriting the commits as it goes, so don't worry about editing/amending any commits as long as you haven't pushed the branch yet.)