GitHub Good Practices

1. For every branch, an issue has to be made denoting what problem is addressed (or vice versa). The issue must have a clear title (e.g. Changing X in Y for reason Z), and the resulting issue number has to be used to name the branch `issue#_XinY`.
2. A single exception on this is the `develop`-branch, which is used as a basis for development for all branches as the future `master`-branch.
3. The `OpenIdeas` GitHub repository is only used for debugging and IEA EBC Annex 60 developments. Any developments of entirely new models should be made on a fork of the repo to a personal git repo, fully developed and tested there, and requested for integration in `OpenIdeas` with a pull request.
4. Before making a GitHub pull request of the `compare`-branch to the `base`-branch, always first do an opposite pull-and-merge of the desired `base`-branch to the `compare`-branch to have a conflict-free pull request to be reviewed by a third person.
5. Use GitHub Flavored Markdown in all issue discussion or in the wiki.