Skip to the content.

Contributing to FHOOEAIST

Thanks for considering to contribute your changes to one of our projects. We are grateful for your support!

The following is a set of guidelines for contributing to the these projects and its packages, which are hosted in the FHOOEAIST organization on GitHub. These are mostly guidelines, not rules (except style guides and review process, these are absolutely rules). Use your best judgment, and feel free to propose changes to this document in a pull request.

Please note that the research group AIST is exclusively financed via external funding, and thus we have no dedicated employees or work hours for the open source projects at GitHub. Most of our contributors provide their work in their free time. Many contributors are students doing this to get acquainted with open source or to add features they want for their thesis. We will make a best effort, but no guarantees, to work on pull requests where you provide code and bug fixes for bug reports. For new features this is exclusively up to the availability and interest of contributors, and in no way, shape or form do we guarantee anything getting done in a specific timeframe (or at all).

Code of Conduct

This project and everyone participating in it is governed by the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to contact@aist.science.

How Can I Contribute?

There are multiple ways of how one can contribute:

Reporting Bugs

Bug Criteria Description
Describe the bug A clear and concise description of what the bug is.
To Reproduce Steps to reproduce the behavior.
Expected behavior A clear and concise description of what you expected to happen.
Optional Real Submitter Who ist the real submitter, in case the creation of the issue was done by proxy.
Optional Link Links to additional information that can help the contributor understand more about this issue.
Optional Priority Priority of this request (Critical, Major, Minor, Trivial; we have labels for blocker and hot).

Submitting Enhancements and Feature Requests

Request Criteria Description
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is.
Describe the solution you’d like A clear and concise description of what you want to happen.
Describe alternatives you’ve considered A clear and concise description of any alternative solutions or features you’ve considered.
Additional Context Any other context or screenshots about the enhancement or feature request.
Optional Real Submitter Who ist the real submitter, in case the creation of the issue was done by proxy.
Optional Link Links to additional information that can help the contributor understand more about this issue.
Optional Priority Priority of this request (Critical, Major, Minor, Trivial; we have labels for blocker and hot).

How do I contribute code

Unsure where to begin contributing? You can start by looking through the good first issue issues. Before doing so, you might want to familiarize yourself with the project. All of them have a “Getting Started” section that you can use to build and use the project.

Most of our core contributors work in academia and are used to guiding junior students into new projects. So if you have any questions, need help, or just don’t know where to start, feel free to drop us a mail.

The issue lifecycle

IssueLifecycle

The review process - Pull Requests

We work with feature branches, meaning that per default we don’t review individual issues, but rather look at a feature as a whole. Only in special cases an issue will be reviewed on its own.

We are never merging code we use rebase. The pull request for code reviews is opened by the developer and is done on one branch on top of the master branch. Please note that before opening a merge request for review, all issues must be tackled in ONE branch and all issues in that branch must be finished before this pull request can be reviewed.

For the implementers (before merge request):

For reviewers:

Issue and Pull Request Labels

Issue Type

Label name Description
bug Bug in project
documentation Improvements or additions to documentation
good first issue Good for a newcomer to get started in the project
hot This is currently a hot topic and should be worked on soon
optimization This is an improvement of an existing feature
story This is a Story summarizing several issues into an overarching feature

Issue Lifecycle

Label name Description
blocked This issue is blocked by another issue (corresponds with blocker)
blocker This issue is blocking another issue (corresponds with blocked)
suggested New feature or improvement suggested to be added
confirmed Issue has been confirmed by contributor to be added to project (replaces suggested)
duplicate This issue is a duplicate of another issue
rejected This issue has been rejected and will not be worked on
review This issue is ready to be reviewed

Style guides

Git Commit Messages

A commit message must start with the corresponding ticket number in GitHub (#TICKETNUMBER) each commit message must have a description which should be in present tense and use imperative voice.

Code Style

For Code Style please refer to the Coding Conventions

Documentation Style

If the maven site plugin is used, the documentation should be inside the src/site/markdown folder again done in markdown files. This then allows to autogenerate a documentation page, which is cohosted to the javadoc of the according projects here. Documentation can be written in any Doxia compatible markdown language as long as the according plugin is configured. More information on this can be found here.

Source code documentation