Contributing to `hypothesis-torch`¶

We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:

Reporting a bug
Discussing the current state of the code
Submitting a fix
Proposing new features
Becoming a maintainer

We Develop with Github¶

We use github to host code, to track issues and feature requests, as well as accept pull requests.

We Use Trunk-based Development, So All Code Changes Happen Through Pull Requests¶

Pull requests are the best way to propose changes to the codebase (we use Trunk-based Development). We actively welcome your pull requests:

Fork the repo and create your branch from main.
If you've added code that should be tested (i.e any changes to the hypothesis-torch package source code), add tests.
If you've changed APIs, update the documentation.
- Include examples, using doctest format!
- We use Google-style docstrings, so please follow that format.
Ensure the test suite passes.
Make sure your code lints.
- Linters are run in Github Actions on every PR, so you can check the status of your PR to see if it passes.
- To reproduce locally, run
```
ruff check
ruff format
```
- ruff can also automatically fix many linting errors with the --fix flag.
- Optionally, you can use the pre-commit hooks by running pre-commit install in the root of the repository, which will run the linters on every commit.
Please use thorough, clear commit messages, with a target audience of end users. These commit messages will be automatically used to generate the changelog.
- Consequently, using Atomic Git Commits is a good practice to keep the changelog clean.
Submit that pull request!

Any contributions you make will be under the MIT Software License¶

In short, when you submit code changes, your submissions are understood to be under the same MIT License that covers the project. Feel free to contact the maintainers if that's a concern.

Report bugs using Github's issues ¶

We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!

If a bug has a serious security concern, please reach out directly to the maintainers.

Write bug reports with detail, background, and sample code¶

Great Bug Reports tend to have:

A quick summary and/or background
Steps to reproduce
Be specific!
Give sample code if you can. Preferably, this is a minimal reproducible example.
What you expected would happen
What actually happens
Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)

People love thorough bug reports. I'm not even kidding.

References¶

This document was adapted from briandk/CONTRIBUTING.md gist and the open-source contribution guidelines for Facebook's Draft

Contributing to hypothesis-torch¶