rich/MeshTerm

0 Fork 0

Files

T

Jean-Pierre MartineauandClaude Opus 5 9b2b4d784b The front door says only what is true

A sweep of the README, CONTRIBUTING and the 0.9.0 changelog entry against the running app.

- Not every screen has a subcommand: the map, dashboard, live feed, watchtower, mesh walk
  and time machine live in the menu only. "Most screens".
- Not every command speaks --json: specimen refuses it. "Nearly every".
- On Windows the download is meshterm-windows-x64.exe, not a file called meshterm.
- Apple silicon is M1 and later; Intel Macs were sold until 2023.
- The global options list gains --ble-pin, --absolute and --platform, which it missed.
- The meshcore library speaks TCP too.
- The standalone builds are single files, so their licence texts are bundled inside, not
  in an archive to extract.
- 64-bit ARM covers the uConsole; the PicoCalc is 32-bit and installs from a checkout.
- --mock keeps its own history database; the caches it shares are not "none of it".

The README, CONTRIBUTING and the PR template disagreed on when a pull request needs an
issue first. All three now say what CONTRIBUTING said: small fixes can come straight in,
anything bigger waits for a yes. CONTRIBUTING drops "or discussion", since Discussions
are off, and points bug reporters at the form, the diagnostics file and Discord. The bug
form link goes to the form rather than its YAML.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-21 11:28:24 -04:00

3.3 KiB

Raw Permalink Blame History

Contributing to MeshTerm

Thanks for wanting to work on MeshTerm. A few things to know before you open a pull request.

Licensing — what happens to your contribution

MeshTerm is licensed under the Apache License, Version 2.0. By opening a pull request, you agree to license your contribution under those same terms — and, going a step beyond what Apache-2.0 alone requires, you additionally grant Jean-Pierre Martineau (the project's copyright holder) the right to relicense your contribution as part of the MeshTerm project, should the project's license ever change in the future. You keep copyright over what you write; you're not signing it away, just granting these usage rights alongside it. No separate form, bot, or signature is needed — opening the PR is how you agree.

If that's not something you're comfortable granting, say so on the PR before it's merged and we'll talk about it, but by default that's the deal for anything merged into this repository.

Before you start

Read CLAUDE.md. It isn't just instructions for AI assistants — it's the actual style guide for this codebase: the terminology (node vs. contact, heard vs. seen, etc.), UX standards for screens/dialogs/menus, and where the reusable building blocks live in code (ui/menus.py, ui/markdown.py, ui/widgets.py, ui/theme.py). New code should read like it always belonged here.
Small fixes can go straight to a pull request. For anything bigger, open an issue first and wait for a yes before writing a lot of code — saves both of us a rewrite.

Making a change

Fork the repo and branch off main.

Set up a dev install:

pip install -e ".[dev]"
git config blame.ignoreRevsFile .git-blame-ignore-revs   # skip the formatting sweeps

Before opening the PR, make sure these all pass:

python -m pytest -q       # tests, including tests/test_gallery.py — the dual-platform
                           # readability gate (screens must stay readable at 72 cols
                           # regular / 53 cols PicoCalc; every PicoCalc case is a hard gate)
ruff check .               # lint
ruff format --check .      # formatting

Keep commits focused; write imperative-mood messages and explain why when it isn't obvious from the diff.
Open the PR against main with a clear description of what changed and why.

Code style

Match the surrounding file: naming, comment density, idiom.
Follow the lexicon and UX standards in CLAUDE.md — one term per concept; don't introduce a synonym for something that already has a name.
New screens, dialogs, and rows go through the existing helpers rather than hand-rolled layout — CLAUDE.md names the enforcement points.

Reporting bugs / requesting features

Open a GitHub issue. For bugs, include what you expected, what happened, and enough to reproduce it — device/platform, MeshCore firmware version if relevant, and steps.

The bug form asks for all of this. Attach the file that meshterm diagnostics --out bug.md writes. No GitHub account? Post it in the #bugs forum on Discord instead.

Questions about any of this, licensing included, are welcome as a GitHub issue before you put work in.

3.3 KiB Raw Permalink Blame History