CONTRIBUTING.md

Contributing to Stable-Baselines3

Important: When submitting issues or pull requests, the use of LLM or code assistants (e.g., Claude or Copilot) must be publicly disclosed.

If you are interested in contributing to Stable-Baselines, your contributions will fall into two categories:

1. You want to propose a new Feature and implement it
   • Create an issue about your intended feature, and we shall discuss the design and implementation. Once we agree that the plan looks good, go ahead and implement it.
2. You want to implement a feature or bug-fix for an outstanding issue
   • Look at the outstanding issues here: https://github.com/DLR-RM/stable-baselines3/labels/help%20wanted
   • Pick an issue or feature and comment on the task that you want to work on this feature.
   • If you need more context on a particular issue, please ask, and we shall provide.

Once you finish implementing a feature or bug-fix, please send a Pull Request to https://github.com/DLR-RM/stable-baselines3

Note: If you do not follow the template (and its mandatory steps), your pull request will be ignored.

If you are not familiar with creating a Pull Request, here are some guides:

• http://stackoverflow.com/questions/14680711/how-to-do-a-github-pull-request
• https://help.github.com/articles/creating-a-pull-request/

Developing Stable-Baselines3

To develop Stable-Baselines3 on your machine, here are some tips:

1. Clone a copy of Stable-Baselines3 from source:

git clone https://github.com/DLR-RM/stable-baselines3
cd stable-baselines3/

2. Install Stable-Baselines3 in develop mode, with support for building the docs and running tests:

pip install -e '.[docs,tests,extra]'

Codestyle

We use black codestyle (max line length of 127 characters) together with ruff (isort rules) to sort the imports. For the documentation, we use the default line length of 88 characters per line.

Please run make format to reformat your code. You can check the codestyle using make check-codestyle and make lint.

Please document each function/method and type them using the following template:

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

    :param arg1: describe what is arg1
    :param arg2: describe what is arg2
    :return: describe what is returned
    """
    ...
    return my_variable

Pull Request (PR)

Important: We do not accept PRs that are fully generated using an LLM/code assistant unless triggered by a maintainer. Use of code assistants (e.g., Claude, Copilot) must be publicly disclosed.

Before proposing a PR, please open an issue, where the feature will be discussed. This prevents from duplicated PR to be proposed and also ease the code review process.

Each PR need to be reviewed and accepted by at least one of the maintainers (@hill-a, @araffin, @ernestum, @AdamGleave, @Miffyli or @qgallouedec). A PR must pass the Continuous Integration tests to be merged with the master branch.

Tests

All new features must add tests in the tests/ folder ensuring that everything works fine. We use pytest. Also, when a bug fix is proposed, tests should be added to avoid regression.

To run tests with pytest:

make pytest

Type checking with mypy:

make type

Codestyle check with black, and ruff (isort rules):

make check-codestyle
make lint

To run type, format and lint in one command:

make commit-checks

Build the documentation:

make doc

Check documentation spelling (you need to install sphinxcontrib.spelling package for that):

make spelling

Changelog and Documentation

Please do not forget to update the changelog (docs/misc/changelog.md) and add documentation if needed. You should add your username next to each changelog entry that you added. If this is your first contribution, please add your username at the bottom too. A README is present in the docs/ folder for instructions on how to build the documentation.

Credits: this contributing guide is based on the PyTorch one.