Contributing Guide

Thank you for your interest in contributing. This guide covers the expectations and process for contributing to this library.

Reporting Bugs

Before opening a bug report, please:

  1. Check the existing issues to see if the bug has already been reported.
  2. Reproduce the problem with the latest version of the library.
  3. Include a minimal, self-contained reproduction case.

Reporting Feature Requests

Before opening a feature request, please:

  1. Check the existing issues to confirm the feature has not already been requested.
  2. Describe the problem you are trying to solve, not just the solution you have in mind. This helps maintainers understand the use case and evaluate alternative approaches.
  3. Keep the scope narrow. A focused request is easier to reason about and more likely to be acted on than a broad one covering multiple unrelated capabilities.

Feature requests are not guaranteed to be implemented. If a request is out of scope or unlikely to be prioritized, it may be closed without action.

Pull Request Guidelines

  • Small is better. A focused, easy-to-review PR is far more likely to be merged promptly than a large one.
  • Update tests. All bug fixes must include a regression test. All behaviour changes must update or add tests accordingly.
  • Update documentation. If the public API or behaviour changes, update the relevant comments, README, or other docs in the same PR.
  • Pass CI. Ensure all existing tests pass locally before opening the PR. New failures introduced by your change will block review.

Maintainer Response Time

This library is maintained on a best-effort basis alongside other priorities. Please allow reasonable time for a response. Pinging a PR repeatedly or opening duplicate issues will not speed up the process.

AI Usage

AI-assisted contributions are welcome. When using AI tools, contributors remain responsible for the final submission. Before opening a pull request:

  • Review and understand every change.
  • Verify that the code follows the project's style and conventions.
  • Write commit messages and pull request descriptions yourself.

Do not submit code that you do not understand or cannot explain during review.