Six repositories, one Discord, no paperwork.
WHERE TO GO
Pick the channel that matches the question
Discord for a conversation, an issue for something reproducible, a private advisory for anything that should not be public until it is fixed.
- Chat
- Discord
- Bugs and features
- GitHub issues, per repo
- Security reports
- private GitHub advisory
- [email protected]
- Contributor agreement
- none
There is no GitHub Discussions board, deliberately. A question that has an answer belongs in Discord where it gets answered in minutes, and a question that turns out to be a defect belongs in the issue tracker of the repository it affects. Extension authors have a dedicated Discord channel.
CONTRIBUTING
Fork, branch, one focused change, with tests
Three of the repositories carry a contributing guide with the specifics; the workflow is the same across all of them.
$# The three repositories with a full contributing guide
git clone https://github.com/altnautica/ADOSMissionControl # browser ground station
git clone https://github.com/altnautica/ADOSDroneAgent # onboard + ground agent
git clone https://github.com/altnautica/ADOSAndroidGCS # native Android GCS
# And the three others
git clone https://github.com/altnautica/ADOSExtensions # first-party extensions + SDK
git clone https://github.com/altnautica/ADOS-MCP # MCP server
git clone https://github.com/altnautica/Documentation # docs.altnautica.comNo CLA, no copyright assignment
Contributing does not transfer anything to us. Each repository states plainly that a contribution is licensed under the GPLv3 that already covers the project. Inbound equals outbound.
A first issue to pick up
The Android ground station labels good-first-issue work, and it is the friendliest entry point: self-contained Kotlin and Compose screens against a well-defined REST and MAVLink surface.
Conduct, in one line
Be useful, be patient, be specific. No marketing copy in the source tree, no named-competitor references, technical scope only. That is the whole standard and it is enforced in review.
RELEASES
Tag-driven, not calendar-driven
Nothing ships on a schedule. A release is a git tag, and the tag triggers a signed build.
Each component tags independently. A Mission Control tag builds the desktop artifacts and rewrites the release notes from its changelog. An extension tag is checked against a publish allowlist, then the archive is packed, signed with the first-party key and attached to the release. Continuous integration also rejects a signing key id that is not on the allowlist, so a mis-set secret fails the release rather than publishing something signed by the wrong key.
The changelog on this site is synced from the GitHub releases, so it is the same record we publish to the repository rather than a curated summary.
ELSEWHERE