Thanks for your interest in contributing to Actix. Contributions are welcome across code, documentation, examples, issue triage, and reviews.

• Ask usage questions in GitHub Discussions or on the Actix Discord.
• Search the relevant repository's issues and discussions before opening a new issue.
• Follow the project's Code of Conduct in all project spaces.

Do not report vulnerabilities in public GitHub issues, pull requests, discussions, Discord, or other public channels.

See the organization Security Policy for the supported versions and how to submit a security report.

Before opening a bug report, search open and closed issues in the affected repository. If you do not find an existing report, open a new issue and include information following the template. The template is important for us to triage your issue.

For substantial features or API changes, start with an issue or discussion before writing a large pull request. Describe the use case, possible API shape, alternatives, and any compatibility concerns.

Small documentation improvements, examples, tests, and straightforward bug fixes can usually go straight to a pull request.

1. Open pull requests against the repository's default branch, main.
2. Keep changes focused. Do not combine unrelated refactors, formatting, and behavior changes in one PR.
3. Add or update tests for behavior changes.
4. Add or update documentation comments, guides, and examples when public behavior changes.
5. Add a changelog entry for each affected released crate. Most Actix crates use CHANGES.md; a few use CHANGELOG.md.
6. Fill out the repository's pull request template, including the PR type, behavior summary, breaking changes, and linked issues. Please do not ignore the template.

Public API changes are checked for semver impact in the main Rust workspaces. Call out intentional breaking changes clearly in the PR description.

Documentation and examples are first-class contributions. Good docs PRs fix missing context, outdated APIs, confusing examples, broken links, or incomplete security notes.

For the [examples repository], keep examples small and focused on one pattern or technique. Prefer current stable APIs and avoid extra infrastructure unless it is the point of the example.

These aren't formal and precise guidelines, but in general:

• Follow the existing style and structure of the repository you are changing.
• Prefer small, direct changes over broad rewrites.
• Keep public APIs minimal and document new public items.
• Avoid adding dependencies unless they are clearly justified.
• Do not introduce new default features without explaining the impact.

Actix crates are generally licensed as MIT OR Apache-2.0. By contributing, you agree that your contribution may be distributed under the licenses used by the repository you submit it to.

AI tools are allowed, but you are responsible for everything you submit.

• Review and understand generated code before opening a PR.
• Make sure generated code is compatible with the repository's license.
• Keep changes small enough for maintainers to review.
• Disclose substantial AI assistance in the PR description.
• Do not submit generated issues, PRs, or security reports that you have not validated yourself.

Maintainers review contributions with the expectation that the author can explain and maintain the submitted change. Any AI slop may result in a ban from the organization.