# How to contribute to Rayhunter

## Filing issues and starting discussions

Our issue tracker is [on GitHub](https://github.com/EFForg/rayhunter/issues).

- If your rayhunter has found an IMSI-catcher, we strongly encourage you to
  [send us that information
  privately.](https://efforg.github.io/rayhunter/faq.html#help-rayhunters-line-is-redorangeyellowdotteddashed-what-should-i-do) via Signal.

- Issues should be actionable. If you don't have a
  specific feature request or bug report, consider [creating a
  discussion](https://github.com/EFForg/rayhunter/discussions) or [joining our Mattermost](https://efforg.github.io/rayhunter/support-feedback-community.html) instead.

  Example of a good bug report:

  - "Installer broken on TP-Link M7350 v3.0"
  - "Display does not update to green after finding"
  - "The documentation is wrong" (though we encourage you to file a pull request directly)

  Example of a good feature request:

  - "Use LED on device XYZ for showing recording status"

  Example of something that belongs into discussion:

  - "In region XYZ, do I need an activated SIM?"
  - "Where to buy this device in region XYZ?"
  - "Can this device be supported?" While this is a valid feature
    request, we just get this request too often, and without some exploratory
    work done upfront it's often unclear initially if that device can be
    supported at all.

- The issue templates are mostly there to give you a clue what kind of
  information is needed from you, and whether your request belongs into the issue
  tracker. Fill them out to be on the safe side, but they are not mandatory.

## Contributing patches

To edit documentation or fix a bug, make a pull request. If you're about to
write a substantial amount of code or implement a new feature, we strongly
encourage you to talk to us before implementing it or check if any issues have
been opened for it already. Otherwise there is a chance we will reject your
contribution after you have spent time on it.

On the other hand, for small documentation fixes you can file a PR without
filing an issue.

Otherwise:

- Refer to [installing from
  source](https://efforg.github.io/rayhunter/installing-from-source.html) for
  how to build Rayhunter from the git repository.

- Ensure that `cargo fmt` and `cargo clippy` have been run.

- If you add new features, please do your best to both write tests for and also
  manually test them. Our test coverage isn't great, but as new features are
  added we are trying to prevent it from becoming worse.

- Please keep your contributions to less than approximately 400 lines of code not counting tests, (going slightly over is fine, we aren't dogmatic about it.) This is because we are not able to give quality code review to contributions larger than that and risk introducing bugs into the system. [There was a study showing 400 LOC is the max most humans can handle.](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/)

If you have any questions [feel free to open a discussion or chat with us on Mattermost.](https://efforg.github.io/rayhunter/support-feedback-community.html)

### Policy regarding AI-generated contributions:

- Please refrain from submissions that you haven't thoroughly understood, reviewed, and tested.
- Please disclose if your contribution was AI-generated
- Descriptions and comments should be made by you

You can read our [full policy](https://www.eff.org/about/opportunities/volunteer/coding-with-eff) and some writing on [our motivations](https://www.eff.org/deeplinks/2026/02/effs-policy-llm-assisted-contributions-our-open-source-projects).

## Making releases

This one is for maintainers of Rayhunter.

1. Make a PR changing the versions in `Cargo.toml` and other files.
   This can be done by running `scripts/set-versions.sh VERSION_NUM`.

2. Merge the PR, make a tag, and push the tag to GitHub. Pushing the tag should
   trigger the [release workflow](https://github.com/EFForg/rayhunter/actions/workflows/release.yml).

3. Write changelog, edit it into the release, announce on mattermost.
