Where to ask, file, and contribute
Capa is a personal project but an open one. The channels below are real and monitored: questions, issues, security reports, and pull requests all have a real effect on direction at this stage.
Four ways in
GitHub Discussions
Open-ended questions, design conversations, "how do I…?" help. Use this when you are not sure whether your message is a bug, a feature request, or a question.
Issues
Concrete bug reports and feature proposals. Two YAML forms collect the fields most likely needed; blank issues are off, so reports never come in half-empty.
Security advisories private
For a way to bypass the capability discipline, escape attenuation, or break Capa's security properties. Only maintainers see the report. Full policy.
Pull requests
Small fixes can come straight as a PR. Larger changes deserve an issue first to align on scope. The CONTRIBUTING guide covers dev setup and architecture.
The short version
The full CONTRIBUTING.md is canonical. The essentials:
Clone and install
$ git clone https://github.com/nelsonduarte/capa-language
$ cd capa-language && pip install -e .Run the tests
python -m unittest discover tests: over 4,000 tests, a couple of minutes.
Open an issue first
For anything more than a small fix. Avoids the worst kind of PR: good work that cannot be accepted because the direction is wrong.
One concern per PR
A PR that fixes a bug and adds a feature is two PRs. Commit messages: imperative, short title (≤ 70 chars).
Where contributions land best
Help wanted
- Analyzer bugs: a program that should compile and does not, or vice versa.
- Test coverage around capabilities and consume.
- Realistic examples/: a small parser or networking client over synthetic demos.
- Libraries written in Capa. The ecosystem is the gap; a small, well-tested library with an honest capability surface is worth more than any compiler patch.
- Reports from real use where the Wasm backend, LSP, or formatter diverges from the docs.
Not currently a fit
- Large refactors of analyzer or transpiler without a prior design discussion.
- New built-in capabilities: the nine are deliberate.
- Major runtime dependencies: the compiler has zero outside stdlib.
- Macros, custom syntax, async/await: out of scope for v1.
- LLVM backend or self-hosting: far-future, not for the 1.0 line.
Show up
A thoughtful issue, a small fix, or a use case from the field has a real effect on direction. Drop in.