Skip to content

Latest commit

 

History

History
75 lines (52 loc) · 3.38 KB

CONTRIBUTING.md

File metadata and controls

75 lines (52 loc) · 3.38 KB
Raw

Contributing to TiddlyMap

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!

If you want to contribute source code…

Signing the CLA

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).

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.

Pull requests (PRs)

Please take care of the following:

  1. Send pull request to the develop branch of the repository – not the master branch!

  2. Only commit files you manually changed – never commit autogenerated files. For exampledo not commit files from the docs or dist folder. Also note that the version number of the plugin.info file is increased on every build which means the file has automatically changed, yet, it should not be committed.

  3. 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:

  4. Update before starting to code: Before doing a PR. Always rebase your local repo to reflect the latest upstream changes. This usually means:

    1. git fetch --all
    2. git checkout develop
    3. git rebase origin

Coding style

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
  • …