Contributing

Full rules live in .github/CONTRIBUTING.md — this page is the map.

Where things go

Type	Destination
Reproducible bug	Issue → Bug report
Concrete feature with a workflow	Issue → Feature request
"How do I...", setup, usage	Discussions → Q&A
Rough idea	Discussions → Ideas
Setups, screenshots	Discussions → Show and tell
Vulnerability	Security advisory — never a public issue

Blank issues are disabled. Every category has a form; required fields are required.

Issue rules

• Search first; duplicates get closed with a link.
• One bug per issue.
• Reproduction steps, device, Android version and app version are mandatory — missing them gets one request, then closure.
• No requests to bypass Android security or permissions.

PR rules

• Fork, branch from main, one focused change per PR.
• ./gradlew assembleDebug must pass locally.
• Fill the PR template — unchecked boxes without a reason block review.
• No reformatting of untouched files, no unrelated refactors, no build output, no keystores or personal paths.
• CI must be green: it builds debug + release and fails if their signers differ.
• Force-push after review starts is discouraged — add commits instead.

Commit style

fix(radar): classify Apple type 0x0F as action modal
feat(ui): adaptive launcher icon
ci: verify debug/release signer match

Types: feat, fix, docs, refactor, test, ci, chore. Body explains why when the subject does not.

Code style

• Kotlin official style, match the surrounding code.
• No hardcoded strings — res/values/strings.xml.
• Generators stay pure (no Android APIs) so they can be unit tested.
• Public API changes (routes, settings keys, intent actions) call out migration impact in the PR body.

Review

Maintainer reviews before merge. Feedback is about correctness, security, data loss, edge cases and coverage — not style bikeshedding.