01
Code
Bug fixes, features, and the unglamorous stuff — dependency bumps, flaky test fixes, performance work.
- Good first issues labelled in every repo
- RFCs for anything bigger than a bugfix
- Review from an active maintainer, not a queue
Team
No CV required. Start anywhere.
Every contributor here started the same way — found something broken, or something missing, and fixed it. There's no application process before that first PR.
Ways in
Code isn't the only way to help.
Docs, design, translation and field feedback are all real contributions, and all get reviewed the same way code does.
02
Docs & writing
Plain-language notes, install guides, and write-ups from your own deployment are all things we're consistently short on.
- Plain-language notes for practitioners
- Field write-ups from real deployments
- Translation into languages we don't cover yet
03
Field feedback
If you run one of our tools, the sharpest feedback we get is from people using it under real conditions, not a demo.
- Bug reports from real deployments
- Feature requests that come from actual use
- No feedback form — just open an issue
First PR, step by step
- 01
Pick something small first
Every repo keeps a "good first issue" label. Small and real beats big and abandoned.
- 02
Open a PR
No CLA, no pre-approval needed for small fixes. Bigger changes start as an RFC issue instead.
- 03
Get reviewed by someone who'll actually merge it
Review comes from an active maintainer on that product, not a queue — usually within a few days.
What we look for
Not credentials — a PR that fixes the actual problem, tested, and scoped to one thing. We'd rather review five small changes than one enormous one, and we'll say so if a PR should be split up.
Your first PR is welcome.
Small, real, and reviewed by someone who'll actually merge it — that's the whole bar.