TiddlyMap is an open source project and as such warmly welcomes contributions from the community to improve the software or anything else related to the project. This includes ideas, feature requests, bug reports, code, documentation, graphics etc.
If you want to contribute to TiddlyMap's success, please create a GitHub issue first, so it is possible to discuss the contribution beforehand!
Contributors of source code and other digital artifacts (e.g. images) included in the software need to sign a so called contributor license agreement (CLA). By signing the agreement, you as the contributor assert that you own the copyright of your contribution and that you agree to license it to the TiddlyMap project and its original creator (me). This agreement is necessary for the legal protection of the TiddlyMap project and its users (licensees) against copyright infringements. It does not change your rights to use your contributions for any other purpose.
Create a pull request on GitHub (in the master
branch) in which
you add your name to the existing list of contributors (scroll to
the very bottom of the document).
- For individuals, please sign CLA-INDIVIDUAL
- Entities use CLA-ENTITY
The CLAs were generated via Harmony (HA-CLA-E-LIST) Version 1.0
Note: What to do, when not owning the copyright in the entire work of authorship?
In this case, please clearly state so in advance. Otherwise it is assumed that you are the legal copyright holder of the contributed work! Please provide links and additional information that clarify under which license the rest of the code is distributed.
Please take care of the following:
-
Send pull request to the
develop
branch of the repository – not the masterbranch
! -
Only commit files you manually changed – never commit autogenerated files. For exampledo not commit files from the
docs
ordist
folder. Also note that the version number of theplugin.info
file is increased on every build which means the file has automatically changed, yet, it should not be committed. -
Squash your commits into a single commit in case you need to modify your PR after creating it. This helps to keep the commit history clean and to make your changes comparable. See also:
-
Update before starting to code: Before doing a PR. Always rebase your local repo to reflect the latest upstream changes. This usually means:
git fetch --all
git checkout develop
git rebase origin
Use the same coding style as present in the project's source code. I'll add a style guide at some point in the future.
Some hints:
- double quotes
- 2 Spaces for indentation
- 80 characters per line (maximum!!)
- Opening braces go on the same line
- …