Contributing

Contributing

Pull requests are welcome. For significant changes, please open an issue first to discuss the proposal.

Ways to help that are not code

Report what you see on the road	The data is the product. More reports from more places make Roadstr better for everyone
Test on real hardware	Above all MeshCore radios (the checklist is §12 of the specification), and voice search on a range of phones
Translate	Irish and Maltese most need a native speaker's review; the newest texts exist only in English and Italian — see Localisation
Add public-transport coverage	Add your operator's open feed to Transitous — guide
Fix map data	Many warnings and limits come from OpenStreetMap; fixing it there helps every app
Report bugs	Issues, with the version and the steps. See Troubleshooting

Before you write code

1. Read Architecture and Build from source.
2. Build and run the tests on a clean checkout.
3. Look at how a neighbouring feature is done; this project prefers boring, bounded, well-tested code.

Code style

• All doc-comments and inline comments are in English.
• Complex algorithms get numbered step comments.
• Nostr protocol references cite the relevant NIP.
• Fixes for the Flutter 0.5.x line go to the flutter-maintenance branch.

What a good pull request contains

• Tests. Kotlin JVM tests for logic (cd android && ./gradlew :app:testDebugUnitTest); a Dart contract test when you add something the build, the manifest or the documents must keep true (flutter test).
• Regenerated resources, if you touched translations: flutter gen-l10n and the generators — the contract tests fail if a generated file is stale.
• Strings in English and Italian at least, through the generators. Do not hand-edit generated XML.
• Privacy honesty. A new network request is disclosed in the UI where it happens, in Privacy and in the README, and a test pins it. A new permission is justified in the manifest and in the docs.
• No secrets — no keys, wallet URIs, bunker links or personal data in code, tests, fixtures or commit messages. The repository is public.
• Docs. Update the CHANGELOG, and the README or the relevant page when behaviour changes.
• A real description. Say what changed and why, and what you did not verify (on-device, a specific phone, real relays).

Commit messages

Short imperative subjects with a scope, for instance feat(speech): …, fix(explore): …, build(android): …, docs: …, i18n(speech): …, test: …. Explain the reason in the body when it is not obvious.

Security

If you find a vulnerability — for example in signing, key handling, the import of old data or event verification — please do not post exploit details in a public issue. Open an issue that only asks for a private channel, and the maintainers will reply.

Licence of contributions

By contributing you agree that your work is released under the MIT licence.