First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
OpenSarToolkit
is an open source project and we love to receive contributions from our community — you! There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into the lib itself.
Warning
Please, don't use the issue tracker for support questions. Instead, check if discussion channels can help with your issue.
Responsibilities:
- Ensure cross-platform compatibility for every change that's accepted. Windows, Mac, Debian & Ubuntu Linux.
- Ensure that code that goes into core meets all requirements in the commitizen checklist
- Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
- Don't add any classes to the codebase unless absolutely needed. Err on the side of using functions.
- Keep feature versions as small as possible, preferably one new feature per version.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See our Code of Conduct.
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸! If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
!DANGER!
If you find a security vulnerability, do NOT open an issue. Email [email protected] instead.
When filing an issue, make sure to answer the questions predifined in the issue template, it will help us reproduce the bug and elp you debuging it.
If you find yourself wishing for a feature that doesn't exist in OpenSarToolkit
, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that OpenSarToolkit
has today have been added because our users saw the need. Open an issue on our issues list on GitHub which describes the feature you would like to see, why you need it, and how it should work.
To install the development environment of the OpenSarToolkit
lib, create a new virtual environment:
$ cd OpenSarToolkit
$ python -m venv venv
(venv)$ source venv/bin/activate
Once in the venv, you can install GDAL
(https://pypi.org/project/GDAL/) SNAP
(http://step.esa.int/main/download/) and ORFEO
(https://www.orfeo-toolbox.org/download/). then install the lib in development mode:
$ pip install -e .[dev]
This will install the pre-commit
hooks that will be run each time you commit to the repository.
Note
You are not force to use en venv
to run ost
but make sure that your dependencies are compatible
For something that is bigger than a one or two line fix
Create your own fork of the code
Do the changes in your fork
If you like the change and think the project could use it:
Be sure you have followed the code style for the project.
run the test suit by running in the root folder of the lib:
python -m pytest
Send a pull request using the provided template
To publish an OST new version:
Wait for the test to run and complete on
main
run the commitizen command locally
cz bump
You will see on your screen something like:
bump: version 0.12.5 → 0.12.6 tag to create: 0.12.6 increment detected: PATCH
Push to
main
(the commit is already created by thecz bump
command)create a new release using the new tag name and the autogenerate report. It will trigger the publication on pipy.
✨ Happy contribuing ! ✨