Monty uses GitHub Pull Requests to integrate code changes.

Before Making a Pull Request

Contributor License Agreement

Before we can accept your contribution, you must sign the Contributor License Agreement (CLA). You can view and sign the CLA now or wait until you submit your Pull Request.

See the Contributor License Agreement page for more on the CLA.

First-Time Contributor

Before submitting a Pull Request, you should set up your development environment to work with Monty. See the development Getting Started guide for more information.

Overall Workflow

Identify an issue to work on.
Ensure your fork has the latest upstream main branch changes (if you don't have a fork of the Monty repository or aren't sure, see the development Getting Started guide):
```
git checkout main
git pull --rebase upstream main
```
Create a new branch on your fork to work on the issue:
```
git checkout -b <my_branch_name>
```
Implement your changes. Keep in mind any tests or benchmarks that you may need to add or update.
If you've added/deleted/modified code, test your changes locally via:
```
pytest
```
Run ruff check to make sure your code adheres to our linting rules.
Push your changes to your branch on your fork:
```
git push
```
Create a new GitHub Pull Request from your fork to the official Monty repository.
Respond to and address any comments on your Pull Request. See Pull Request Flow for what to expect.
Once your Pull Request is approved, it will be merged by one of the Maintainers. Thank you for contributing! 🥳🎉🎊

Additional Recommendations for Code Changes

It is recommended to add unit tests for any new feature you implement. This makes sure that your feature continues to function as intended when other people (or you) make future changes to the code. To get a detailed coverage report use pytest --cov --cov-report html.
Run pytest, ruff check, and ruff format to make sure your changes don't break any existing code and adhere to our style requirements. If your code doesn't pass these, it can not be merged.
To check whether a code change led to different behavior of the algorithm, you can run our benchmark experiments before and after the change and check for changes. You will not be able to replicate the reported benchmark results, but our team members may run your code on our hardware to check for any changes on those before merging your PR.
Make sure that your code is properly documented. Please refer to our Style Guide for instructions on how to format your comments.
If applicable, please also update or add to the documentation on readme.com. For instructions on how to do this, see our guide on contributing documentation.
Use callbacks for logging, and don’t put control logic into logging functions.
Note that the random seed in Monty is handled using a generator object that is passed
where needed, i.e. by initializing the random number generator with
```
rng = np.random.RandomState(experiment_args["seed"])
```
This rng is then passed to the various classes, and can be accessed in the sensor
modules, learning modules, and motor system with self.rng. Thus to use a random
numpy method, call it with e.g. self.rng.uniform() rather than np.random.uniform()

Additional Recommendations for Documentation Changes

run vale . to check spelling
- Install instructions are here
run python -m tools.github_readme_sync.cli check docs to check links.
- To install the tool, run pip install -e '.[dev,github_readme_sync_tool]'
run python tools/future_work_widget/run_local.py to render the future work table locally.
- To install run pip install -e '.[github_readme_sync_tool,future_work_widget_tool]'

You can find more info in our page on editing the documentation.

Help Us Make This Page Better

All our docs are open-source. If something is wrong or unclear, submit a PR to fix it!

Make a Contribution

Learn how to contribute to our docs