Thank you for considering contributing to SatPy! SatPy's development team is made up of volunteers so any help we can get is very appreciated.
Contributions from users are what keep this community going. We welcome any contributions including bug reports, documentation fixes or updates, bug fixes, and feature requests. By contributing to SatPy you are providing code that everyone can use and benefit from.
The following guidelines will describe how the SatPy project structures its code contributions from discussion to code to package release.
For more information on contributing to open source projects see GitHub's Guide.
- Make sure you have a GitHub account.
- Submit a ticket for your issue, assuming one does not already exist.
- If you're uncomfortable using Git/GitHub, see Learn Git Branching or other online tutorials.
- If you are uncomfortable contributing to an open source project see:
- How to Contribute to an Open Source Project on GitHub video series
- Aaron Meurer's Git Workflow
- How to Contribute to Open Source
- See what issues already exist. Issues marked good first issue or help wanted can be good issues to start with.
- Read the
indexfor more details on contributing code. - Fork the repository on GitHub and install the package in development mode.
- Update the SatPy documentation to make it clearer and more detailed.
- Contribute code to either fix a bug or add functionality and submit a Pull Request.
- Make an example Jupyter Notebook and add it to the available examples.
Not possible. If something breaks because of your contribution it was our fault. When you submit your changes to be merged as a GitHub Pull Request they will be automatically tested and checked against coding style rules. Before they are merged they are reviewed by at least one maintainer of the SatPy project. If anything needs updating, we'll let you know.
You can expect the SatPy maintainers to help you. We are all volunteers, have jobs, and occasionally go on vacations. We will try our best to answer your questions as soon as possible. We will try our best to understand your use case and add the features you need. Although we strive to make SatPy useful for everyone there may be some feature requests that we can't allow if they would require breaking existing features. Other features may be best for a different package, PyTroll or otherwise. Regardless, we will help you find the best place for your feature and to make it possible to do what you want.
We, the SatPy maintainers, expect you to be patient, understanding, and respectful of both developers and users. SatPy can only be successful if everyone in the community feels welcome. We also expect you to put in as much work as you expect out of us. There is no dedicated PyTroll or SatPy support team, so there may be times when you need to do most of the work to solve your problem (trying different test cases, environments, etc).
Being respectful includes following the style of the existing code for any code submissions. Please follow PEP8 style guidelines and limit lines of code to 80 characters whenever possible and when it doesn't hurt readability. SatPy follows Google Style Docstrings for all code API documentation. When in doubt use the existing code as a guide for how coding should be done.
The SatPy developers (and all other PyTroll package developers) monitor the:
- Mailing List
- Slack chat (get an invitation)
- GitHub issues
Any contributions should start with some form of communication (see above) to let the SatPy maintainers know how you plan to help. The larger the contribution the more important direct communication is so everyone can avoid duplicate code and wasted time. After talking to the SatPy developers any additional work like code or documentation changes can be provided as a GitHub Pull Request.