Contribute to AixLib

Thanks for contributing to AixLib, the following page describes tasks and responsibilities by changing code. We encourage you to follow this workflow, which is inspired by Annex60, BuildingSystem and IDEAS.

If you are a member of RWTH-EBC you can directly write to the repository. If you are not member you need to create a fork of AixLib.

---

We are currently restructuring this part of the wiki, see issue #356

---

If you have never contributed to AixLib, you can have a look at our short tutorial on how to make your first contribution to AixLib. Look out for the good first issue label on our Issue Tracker!

In addition, there are several other ways in which you can contribute to AixLib:

• Report an error/suggest an improvement
• Add a new model

---

This is the old page, which we will keep until the new one is finished:

Bugfixes

As a developer:

1. Open a new issue in the Issues section, assign it to the one who can address it (which may be you) and apply the bug label. The issue has to have a clear title (e.g. Bug in Class Y).
2. Create a new branch starting from the master, call this branch according to the created issue 'issue##_BugClassY'
3. Document your changes in rather small steps/commits. Try to use choose short commit messages (maximum 140 characters). You may want to include in the commit message a string such as #17. This will automatically add a link to the commit from the issue.
4. Watch the evolution of the master if it changes, merge the latest version into your branch.
5. Increase the version number in README and package.mo of AixLib in a single commit.
6. Create a pull request with master as base and your branch as compare. And assign the pull request to someone for reviewing and merging it into the master.

As a reviewer/admin:

1. When reviewing others code, add your comments on the issue tracker or even better start a review. If the revisions need further work, assign these to the original author.
2. If the revisions are reviewed and correct, accept the pull requests, delete the branch and close the issue. Whenever you accept a pull request into the master, you need to make sure to publish a new release. In the Releases section hit the Draft a new release button, enter the correct new version number and chose a self explaining release title (e.g. v0.2.0 or "Bugfix in Class Y"). Furthermore, create a pull request with development as base and master as compare, you can accept this pull request by yourself, as the changes have already been reviewed.

New/improve feature

As a developer:

1. Open a new issue in the Issues section, assign it to the one who can address it (which may be you). The issue has to have a clear title (e.g. New Feature in Class X).
2. Create a new branch starting from the development, call this branch according to the created issue 'issue##_FeatureClassY'
3. Document your changes in rather small steps/commits. Try to use choose short commit messages (maximum 140 characters). You may want to include in the commit message a string such as #17. This will automatically add a link to the commit from the issue.
4. Watch the evolution of the development if it changes, merge the latest version into your branch.
5. Create a pull request with development as base and your branch as compare. And assign the pull request to someone for reviewing and merging it into the development.

As a reviewer:

1. When reviewing others code, add your comments on the issue tracker or even better start a review. If the revisions need further work, assign these to the original author.
2. If the revisions are reviewed and correct, accept the pull requests, delete the branch and close the issue.

---

Behind the Scenes