How to contribute

The canonical document is .github/CONTRIBUTING.md. This wiki section unpacks it and adds context about how the codebase is actually maintained.

The short version

1. File an issue first for non-trivial changes. The maintainers may decide your idea is better as a third-party crate.
2. Fork, branch, code, test, open a PR.
3. The PR gets labelled Needs Review. A maintainer reviews when they can.
4. After acceptance, your commits are rebased onto main in a separate batched PR alongside other accepted changes and internal Cloudflare changes. Once that lands, your PR closes.

This batched-rebase pattern is how Pingora's public history stays consistent with Cloudflare's internal repository. It also means you won't usually see your commits land under your own merge commit — they'll be authored by you but applied as part of a batch.

Internal vs external priority

CONTRIBUTING is explicit:

Currently, internal contributions will take priority. Today Pingora is being maintained by Cloudflare's Content Delivery team, and internal Cloudflare proxy services are a primary user of Pingora. We value the community's work on Pingora, but the reality is that our team has a limited amount of resources and time. We can't promise we will review or address all PRs or issues in a timely manner.

Translation: large feature PRs may sit. Small, focused PRs (typo fixes, one-function bug fixes, documentation) move much faster.

Pages in this section

• Development workflow — branches, building, the iteration loop
• Testing — cargo test, integration tests, what's flaky
• Debugging — logs, common errors, stuck behaviors
• Patterns and conventions — error handling, async style, file layout
• Tooling — clippy, rustfmt, cargo, CI

Code of Conduct

Pingora follows the Contributor Covenant Code of Conduct inherited from the broader Cloudflare OSS organization. Violations can result in repository or organization-wide bans.

Contact

For questions outside the issue tracker, the README points at opensource@cloudflare.com.