Contributing¶
Guidelines¶
We welcome contributions to the library! If you have a bug fix or new feature that you would like to contribute, please follow the steps below:
- Fork the repository on GitHub.
- Clone the repository to your local machine.
- Create a new branch for your bug fix or feature.
- Make your changes and test them thoroughly, making sure that it passes all current tests.
- Commit your changes and push the branch to your fork.
- Open a pull request on the main repository.
Code of Conduct¶
All contributors are expected to follow the project's code of conduct, which is based on the Contributor Covenant.
Reporting Bugs¶
If you find a bug in the library, please report it by opening an issue on GitHub. Be sure to include the version of the library you're using, as well as any error messages or tracebacks and a reproducible example.
Requesting Features¶
If you have a suggestion for a new feature, please open an issue on GitHub. Be sure to explain the problem that you're trying to solve and how you think the feature would solve it.
Submitting Pull Requests¶
When submitting a pull request, please make sure that you've followed the steps above and that your code has been thoroughly tested. Also, be sure to include a brief summary of the changes you've made and a reference to any issues that your pull request resolves.
Code formatting¶
Compclasses uses black and isort with the following parameters for code formatting:
As part of the checks on pull requests, it is checked whether the code follows those standards. To ensure that the standard is met, it is recommended to install pre-commit hooks:
Developing¶
Let's suppose that you already did steps 1-3 from the above list, now you should install the library and its developing dependencies in editable way.
First move into the repo folder: cd deczoo
.
Then:
Now you are ready to proceed with all the changes you want to!
Testing¶
Once you are done with changes, you should:
- add tests for the new features in the
/tests
folder -
make sure that new features do not break existing codebase by running tests:
Docs¶
The documentation is generated using mkdocs-material, the API part uses mkdocstrings.
If a breaking feature is developed, then we suggest to update documentation in the /docs
folder as well, in order to describe how this can be used from a user perspective.