> For the complete documentation index, see [llms.txt](https://time-series-features.gitbook.io/pyspi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://time-series-features.gitbook.io/pyspi/development/development/contributing-to-pyspi.md). # Contributing to pyspi We deeply appreciate your interest in contributing to *pyspi*. Contributions play a vital role in the continual development and enhancement of *pyspi*, a project built and enriched through community collaboration. By participating in this project, you are contributing to the broader community and helping shape the future of this software. Code is not the only way to contribute to *pyspi*. Reviewing pull requests, answering questions to help others and aid in troubleshooting, organising and teaching tutorials, improving documentation are all priceless contributions to the project. ## Our Code of Conduct *pyspi* is committed to fostering a welcoming and inclusive community. All contributors and participants are expected to adhere to our Code of Conduct. Before engaging with the *pyspi* project, please take some time to read our [*Code of Conduct*](/pyspi/development/development/code-of-conduct.md) and ensure that you abide by its terms. We believe in a respectful and harassment-free experience for everyone, and our Code of Conduct outlines our expectations for participant behaviour. ## Types of contributions we seek *pyspi* thrives on a wide range of contributions, and we welcome your ideas, feedback and code. Here are some of the ways you can contribute to the project: * **Integrating new SPIs**: We strive to provide the most comprehensive toolkit of SPIs. If you have ideas for new SPIs or improvements to existing ones, we are eager to hear and collaborate with you. Any pairwise dependence measure, provided it is accompanied by a published research paper, typically falls within our scope for consideration in the *pyspi* library. For an in-depth guide on how you can integrate new SPIs into *pyspi*, see [here](/pyspi/development/development/incorporating-new-spis.md). * **Bug fixes**: Identifying and fixing bug are critical to maintaining the quality and reliability of *pyspi*. We use GitHub issues to track all bugs an feature requests. Feel free to open an issue if you have found a bug or wish to see a feature implemented. * **Documentation**: Enhancing and updating our documentation to make it more comprehensive, up-to-date and user-friendly. If you find a typo in the documentation, or have suggestions for improvements, do not hesitate to send an email to the mailing list or preferably submit a GitHub pull request. * **Examples and tutorials**: Creating practical and informative examples or tutorials to assist users in understanding and utilising *pyspi*. * **Troubleshooting:** Another way to contribute is to report issues you are facing and give a "thumbs up" on issues that others reported and that are relevant to you. It also helps us if you spread the word by referencing the project from your blogs and articles, link to it from your website, or simply 'star' the project on GitHub to say "I use it". ## Bug Reporting Guidelines We value bug reports as they play a crucial role in improving the quality of *pyspi*. We use GitHub issues to track bug requests, so if you encounter issues using this package, do not hesitate to submit a ticket to the [Bug Tracker](https://github.com/DynamicsAndNeuralSystems/pyspi/issues). Before submitting a ticket, it is recommended to check that your issue complies with the following rules before submitting: * Verify that your issue is not currently being addressed by an [existing ticket](https://github.com/DynamicsAndNeuralSystems/pyspi/issues). * Ensure that your bug report complies with the *pyspi* bug report guidelines. ### Submitting an ideal bug report When submitting a bug report to the issue tracker in GitHub, please ensure that you follow these guidelines. This will streamline the resolution process and allow community members to provide good feedback. A good bug report shouldn’t leave others needing to chase you up for more information. Please try to be as detailed as possible in your report: * The ideal bug report should contain a **short reproducible code snippet**, this way anyone can try to reproduce the bug easily. If your snippet is longer than 50 lines, please link to a gist or GitHub repo. * If not feasible to include a reproducible snippet, please be specific about what classes/functions involved. * If an exception is raised, please **provide the full traceback**. * Include your **operating system, architecture** and **version number**, as well as your Python **version**. * Ensure all code snippets and error messages are formatted in [appropriate code blocks](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks). *** ## Pull Request Guidelines To ensure a smooth and efficient review process, we ask that you adhere to the following guidelines when submitting a pull request: * **Include tests:** If your changes include new features or modifications to existing ones, please include appropriate tests. Well-written tests are fundamental to ensuring the reliability and stability of *pyspi*. To get an idea of the structure and conventions for writing unit tests, see the [source code](https://github.com/DynamicsAndNeuralSystems/pyspi/tree/main/tests) for existing *pyspi* unit tests. Note we use [***pytest*** ](https://docs.pytest.org/en/7.4.x/)for all unit testing as standard. * **Update documentation**: If your changes involve user-facing features or significant modifications to existing functionalities, please update the relevant documentation sections. * **Follow Code Standards:** Ensure your code adheres to the coding standards and style guidelines of *pyspi*. Consistent coding styles contribute to the readability and maintainability of the project. * **Compatibility checks**: Verify that your changes are compatible with the supported versions of Python and any other dependencies. All tests should pass on the continuous integration (CI) system after your pull request is submitted. Submitted pull requests are reviewed on a regular basis. The *pyspi* core team evaluates each contribution for its quality, relevance, and alignment with the project's goals. Feedback will be provided, and we expect contributors to engage in a collaborative review process. If a pull request remains inactive for an extended period after feedback has been provided, it may be closed to keep the project's backlog manageable. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://time-series-features.gitbook.io/pyspi/development/development/contributing-to-pyspi.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.