The commit before this one rewrote a hundred and fifty-three files without changing what any of them does. Left alone, that is what `git blame` would name for half the lines in the repo — the formatter, standing in front of whoever actually wrote the line and whatever they were thinking at the time. `.git-blame-ignore-revs` is the file that fixes it. GitHub reads it with no setup at all, so the blame view on the web is already right; locally it needs `git config blame.ignoreRevsFile .git-blame-ignore-revs` once, which is now step two of the dev install in CONTRIBUTING alongside the editable install, since a contributor who never runs it gets the wrong answer silently rather than an error. The file's header states the bar for being in it: whole-tree, provably behaviour-free. That is a deliberately narrow door — an entry here makes a commit invisible to the tool people use to ask why a line looks the way it does, and a commit that changed anything real must never be able to hide behind it. Verified rather than assumed: `git blame` on a line the sweep rewrote now reports `f07f8c1b` from July, which is the commit that actually wrote it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
68 lines
3.0 KiB
Markdown
68 lines
3.0 KiB
Markdown
# 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](LICENSE). 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](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.
|
|
- For anything bigger than a small fix, open an issue first to talk it through before
|
|
writing a lot of code — saves both of us a rewrite.
|
|
|
|
## Making a change
|
|
|
|
1. Fork the repo and branch off `main`.
|
|
2. Set up a dev install:
|
|
```bash
|
|
pip install -e ".[dev]"
|
|
git config blame.ignoreRevsFile .git-blame-ignore-revs # skip the formatting sweeps
|
|
```
|
|
3. Before opening the PR, make sure these all pass:
|
|
```bash
|
|
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
|
|
```
|
|
4. Keep commits focused; write imperative-mood messages and explain *why* when it isn't
|
|
obvious from the diff.
|
|
5. 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](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.
|
|
|
|
---
|
|
|
|
Questions about any of this, licensing included, are welcome as a GitHub issue or
|
|
discussion before you put work in.
|