Contributing

We welcome you to check the existing issues for bugs or enhancements to work on. If you have an idea for an extension to BlocksNet, please file a new issue so we can discuss it.

Make sure to familiarize yourself with the project layout before making any major contributions.

How to contribute

To start developing the library, one must perform following actions:

Clone the repository:

$ git clone https://github.com/aimclub/blocksnet

(Optional) Create a virtual environment as the library demands exact package versions:
```
$ make venv
```
Activate the virtual environment if you created one:
```
$ source .venv/bin/activate
```
Install the library in editable mode with development dependencies:
```
$ make install-dev
```
Install pre-commit hooks:
```
$ pre-commit install
```

Create a new branch based on develop:

$ git checkout -b develop <new_branch_name>

Start making changes on your newly created branch, remembering to never work on the master branch! Work on this copy on your computer using Git to do the version control.
Update tests according to your changes and run the following command:
```
$ make test
```
Make sure that all tests pass.
Update the documentation and README according to your changes.

When you’re done editing and local testing, run:

$ git add modified_files
$ git commit
to record your changes in Git, then push them to GitHub with:
$ git push -u origin my-contribution
Finally, go to the web page of your fork of the BlocksNet repo, and click ‘Pull Request’ (PR) to send your changes to the maintainers for review.

(If it looks confusing to you, then look up the Git documentation on the web.)

Before submitting your pull request

Before you submit a pull request for your contribution, please work through this checklist to make sure that you have done everything necessary so we can efficiently review and accept your changes.

If your contribution changes BlocksNet in any way:

Update the documentation so all of your changes are reflected there.
Update the README if anything there has changed.

If your contribution involves any code changes:

Update the project unit tests to test your code changes.
Make sure that your code is properly commented with docstrings and comments explaining your rationale behind non-obvious coding practices.

If your contribution requires a new library dependency:

Double-check that the new dependency is easy to install via pip or Anaconda and supports Python 3. If the dependency requires a complicated installation, then we most likely won’t merge your changes because we want to keep BlocksNet easy to install.

Contribute to the documentation

Take care of the documentation.

All the documentation is created with the Sphinx autodoc feature. Use .. automodule:: <module_name> section which describes all the code in the module.

If a new package with several scripts:
1. Go to docs/source/BlocksNet and create new your_name_for_file.rst file.
2. Add a Header underlined with “=” sign. It’s crucial.
1. Add your_name_for_file to the toctree at docs/source/blocksnet/api/index.rst
If a new module to the existed package:

Most of the sections are already described in docs/source/BlocksNet , so you can:
- choose the most appropriate and repeat 3-d step from the previous section.
- or create a new one and repeat 2-3 steps from the previous section.
If a new function or a class to the existing module:

Be happy. Everything is already done for you.

After submitting your pull request

After submitting your pull request, Travis-CI will automatically run unit tests on your changes and make sure that your updated code builds and runs on Python 3. We also use services that automatically check code quality and test coverage.

Check back shortly after submitting your pull request to make sure that your code passes these checks. If any of the checks come back with a red X, then do your best to address the errors.

Acknowledgements

This document guide is based at well-written TPOT Framework contribution guide.