Contributing to EAS Station™

Thank you for your interest in improving EAS Station™. We welcome issues, feature proposals, and code contributions that advance experimental emergency alert tooling while keeping the project safe for lab use.

Code of Conduct

Be respectful and constructive. EAS Station™ is maintained by volunteers supporting the public-safety and amateur-radio communities. Provide helpful context, avoid personal attacks, and keep communication focused on building a reliable platform.

Licensing and Copyright

The EAS Station™ source code is dual-licensed under the GNU Affero General Public License v3 (AGPL-3.0) for open-source use and a Commercial License for proprietary use. EAS Station, LLC (KR8MER) retains the project copyright.
By contributing, you agree that your submissions will be licensed under the AGPL-3.0 license and may be redistributed under those terms.

Developer Certificate of Origin (DCO)

This project uses a Developer Certificate of Origin workflow instead of a Contributor License Agreement. The DCO keeps the process lightweight while ensuring that all contributors affirm they have the right to submit their work.

Each commit must contain a Signed-off-by line, which you can add automatically with git commit -s. The signature certifies that you wrote the code or have the rights to pass it on under the project license. The wording of the DCO can be found at developercertificate.org.

Example commit message:

Add new alert visualization panel

Improve the admin dashboard by adding a Highcharts visualization of alert volume.

Signed-off-by: Your Name <you@example.com>

If you contribute on behalf of an organization, ensure you have the necessary authorization to do so before signing off.

How to Contribute

Fork the repository and create a topic branch (feature/..., fix/..., or docs/...).
Follow the development guidelines in AGENTS.md and existing code patterns.
Add tests or documentation that cover your changes when possible.
Update release metadata. Append notes under the [Unreleased] heading in CHANGELOG.md and bump the root VERSION file (plus .env.example) when behaviour changes. The guardrail test tests/test_release_metadata.py enforces this alignment. After a VERSION bump lands on main, a maintainer manually runs the release workflow (Actions → Release → Run workflow) to tag it and publish a signed GitHub Release — see RELEASING.md.
Keep tech-stack attributions in sync. If you bump or add a Python dependency in requirements.txt, also update the matching shield in both of the canonical surfaces below — they cannot be allowed to drift:
- templates/partials/tech_stack_badges.html — the live page footer badge strip (single source of truth, included by templates/base.html).
- README.md — the curated badge block at the top and the exhaustive ## 📚 Attributions & Open-Source Credits table further down.
The drift guard tests/test_tech_stack_badges.py enforces that a curated subset of versioned shields matches the version pinned in requirements.txt, and that system-level dependencies (chrony, gpsd, FFmpeg, eSpeak NG, Icecast, Nginx, Docker, …) remain attributed in both places. Do not inline the badge list back into base.html; the partial is the single source of truth.
Run the test suite or targeted regression checks (alert ingest, SAME generation, GPIO control, audio playout) before opening a pull request so reviewers know nothing critical regressed.
Submit a pull request describing the change, its motivation, and any verification steps performed.

We encourage proposals and discussion via GitHub issues before major changes. Thanks for helping build EAS Station™!

Back to Documentation Index

This document is served from docs/process/CONTRIBUTING.md in the EAS Station™ installation.