Contributing¶

First, thanks for contributing 🎉🎉🎉

Before you get started:

We require contributors to sign a Contributor License Agreement (CLA). We know legal agreements aren't the most exciting part of contributing, so we've put together a short explanation of why we need one, what it means for you, and the full CLA for you to read. You can find everything here.
Interested in contributing? Great! Once you've had a look at the CLA, please email tobias.rohrer@ise.fraunhofer.de. We'll provide you with an editable copy and sort out the signing process with you.

Contributions fall into two categories:

You propose a new feature or report a bug:
Create an Issue and we discuss the design and implementation. Once it's all agreed, one can go ahead and implement it
You want to work on an outstanding issue:
Outstanding issues are labeled help wanted
Pick the issue or feature and comment on the task you want to work on. Ask for more information in the issue if needed.

Once you finish implementation, sent a pull request

If you are not familiar with creating a pull request, here are some guides:

Development¶

To develop NRGISE Open on your machine:

Clone a copy of NRGISE from source:

git clone link
cd link/

Install NRGISE in development mode:

pip install -e '.[dev]'

Codestyle, Typing and Code Documentation¶

We aim to maintain a high level of code quality and readability throughout NRGISE. Before committing your changes, please run:

sh scripts/validate_code.sh

This runs the relevant code quality checks and tests, including:

Code style with Ruff
We use Ruff to enforce consistent Python code style. Ruff can also be integrated into editors such as VS Code and PyCharm. To run it manually:
```
ruff check .
```
Type checking with mypy
NRGISE uses Python type annotations. New code should be properly typed and pass mypy's static type checks. To run it:
```
mypy nrgise tests
```
Tests with pytest
To run the test suite:
```
pytest
```

These checks are also part of our CI pipeline and must pass before a contribution can be merged.

Please also document each public function and method using Google-style docstrings:

def my_function(arg1: type1, arg2: type2) -> returntype:
    """
    Short description

    Args:
        arg1: what is arg1?
        arg2: what is arg2?

    Returns:
        describe what is returned
    """
    ...
    return my_variable

Tests¶

All new features and changes must be tested. Please add or update the corresponding tests in /tests.

Documentation¶

We use mkdocs to document our code.
You can start the local documentation server by running: mkdocs serve.
Change the documentation (located at /docs) if necessary.
Code documentation should be done in google style (see above).

Pull Request (PR)¶

If all tests and style checks pass, you can create a pull request. Each PR will be reviewed by at least one of the maintainers (tobirohrer, RicardaHogl, Nanunanuk).

Other¶

Note: This contribution guide was inspired by the one from Stable-Baselines3.