From 69da13c340fbfd42c7216666159ef09c8a16f255 Mon Sep 17 00:00:00 2001 From: jrd Date: Tue, 21 Jul 2026 18:58:31 +0000 Subject: [PATCH 1/6] Add AGENTS.md for AI-agent contributors MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Points agents at the existing README workflow and Style-and-Tone guide, and adds one rule not covered by either: no smart/curly quotes or apostrophes, since a curly character silently corrupts shell single-quoted strings, JSON, regexes, and code spans in a way plain ASCII never does. πŸ€– Generated with Claude Code --- AGENTS.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 AGENTS.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 000000000..e32f3e078 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,19 @@ +# Jamulus Website β€” Agent Instructions + +Content repo for jamulus.io (wiki/docs). English is the source of truth β€” edits land in English first, then flow to other languages via Weblate/po4a. + +Docs: [README.md](README.md) (workflow, translation process, branch targeting), [Style and Tone guide](https://jamulus.io/contribute/Style-and-Tone) (voice, terminology, capitalisation β€” applies to agents without exception). + +## Rules + +- Smallest possible PRs: one logical change each. +- Edit English source `.md` files only β€” never hand-edit translated-language files or `.po` files; those belong to translators via Weblate. +- **No smart/curly quotes or apostrophes** (`’ β€œ ”`) β€” always straight ASCII `'` and `"`. This isn't a style preference: a curly character pasted into a shell single-quoted string, JSON, a regex, or a code span is not the character the parser expects, and corrupts it silently. Word/Google Docs autocorrect and some LLM output insert these by default β€” check for them explicitly before opening a PR, especially near any code span or CLI example. +- Prefer hedged phrasing over absolute claims where the claim isn't a hard limit (e.g. "discouraged" over "not recommended", "up to N" over "less than N") β€” follows the guide's "give solutions first, avoid overly stylised language" principle. +- British English spelling (colour, minimise, centre). +- Match established terminology exactly: Server/Client (capitalised = a Jamulus app instance) vs. server/client (lowercase = the physical/cloud machine); "person" not "musician"; "sound card" vs. "audio interface" β€” full list in Style-and-Tone.md. + +## Submit + +- Target `next-release` if the change needs translation, `release` if not (README's workflow section explains which). +- Fill out the PR template checklist. From f9d0214ead03aec32648825e3026f51a2a640acc Mon Sep 17 00:00:00 2001 From: jrd Date: Thu, 23 Jul 2026 19:07:23 +0000 Subject: [PATCH 2/6] Expand quotes rule into a full Punctuation section Moves the substantive dash/hyphen/quote/ellipsis guidance into Style-and-Tone.md (applies to all contributors, not just agents) next to the existing Units section, which does the same kind of micro-convention work. AGENTS.md keeps a pointer plus the one rule that's genuinely agent-specific: check the diff for stray curly characters near code, since that's an LLM/paste failure mode rather than a human typing habit. Unifies the two prior asks in this area: the original "always straight ASCII" quotes rule (safe wherever the text could be pasted into a shell/JSON/regex/code span) and the "use en/em dash where typography calls for it" split from PR #1159, under one principle -- machine context stays ASCII, human-read prose gets the correct character. --- AGENTS.md | 2 +- contribute/en/Style-and-Tone.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index e32f3e078..78edb387f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -8,7 +8,7 @@ Docs: [README.md](README.md) (workflow, translation process, branch targeting), - Smallest possible PRs: one logical change each. - Edit English source `.md` files only β€” never hand-edit translated-language files or `.po` files; those belong to translators via Weblate. -- **No smart/curly quotes or apostrophes** (`’ β€œ ”`) β€” always straight ASCII `'` and `"`. This isn't a style preference: a curly character pasted into a shell single-quoted string, JSON, a regex, or a code span is not the character the parser expects, and corrupts it silently. Word/Google Docs autocorrect and some LLM output insert these by default β€” check for them explicitly before opening a PR, especially near any code span or CLI example. +- **Punctuation**: follow the Punctuation section in Style-and-Tone.md (dash/hyphen choice, curly vs. straight quotes, ellipsis). Word/Google Docs autocorrect and some LLM output insert curly characters by default even inside code β€” before opening a PR, check your diff specifically for stray curly quotes/dashes near any code span, CLI example, or other machine-parsed value. - Prefer hedged phrasing over absolute claims where the claim isn't a hard limit (e.g. "discouraged" over "not recommended", "up to N" over "less than N") β€” follows the guide's "give solutions first, avoid overly stylised language" principle. - British English spelling (colour, minimise, centre). - Match established terminology exactly: Server/Client (capitalised = a Jamulus app instance) vs. server/client (lowercase = the physical/cloud machine); "person" not "musician"; "sound card" vs. "audio interface" β€” full list in Style-and-Tone.md. diff --git a/contribute/en/Style-and-Tone.md b/contribute/en/Style-and-Tone.md index 197d2d6b6..ac4bf0526 100644 --- a/contribute/en/Style-and-Tone.md +++ b/contribute/en/Style-and-Tone.md @@ -101,6 +101,21 @@ Jamulus is "Free and Open Source (FOSS)" (not "free software" or "open source") "Server List" This is the list of Servers maintained by a Directory. A Server registers with a Directory to be _listed_ in that Directory’s _server list_. +## Punctuation + +One governing question for every dash, quote, or ellipsis: is this character doing a job a parser depends on, or is it doing prose work for a human reader? Machine-context wins every time; only prose gets the fancier character. + +Never use a curly/typographic character inside a code span or fenced code block, an HTML attribute, YAML frontmatter, a CLI flag, a Markdown list/checkbox bullet, an ISO 8601 date (`2021-03-17`), a version/build string (`3.7.0dev-123456`), a URL, or anything meant to be copied and pasted verbatim (a shell command, a JSON snippet, a config value). In all of these, a smart quote, em-dash, or en-dash is either a parser error or a silent corruption of a value the reader will paste elsewhere. Plain ASCII `-`, `'`, `"` only. + +Everywhere else β€” prose meant to be read, not executed β€” use the correct typographic character: + +- **Hyphen (`-`)**: compound modifiers only (`low-bandwidth`, `text-wrapping`). If you can mentally replace it with "to" or read it as a parenthetical break, it isn't a hyphen's job. +- **En dash (`–`), no surrounding spaces**: numeric ranges (`0–16`, `30–50 ms`, `pages 16–18`). +- **En dash (`–`), with spaces**: a "Title – Subtitle" page title, matching the existing pattern in `Command-Line-Options.md`, `Privacy-Statement.md`, and `2020-03-28-Server-Rpi.md`. +- **Em dash (`β€”`), with spaces on both sides**: a parenthetical aside, appositive, or sentence interruption β€” matches the site's own pre-existing usage (`misc/1-index.md`). Never use a doubled hyphen (`--`) as a substitute; it's a typewriter-era workaround, not a typographic period. +- **Curly quotes/apostrophes (`’ β€œ ”`)**: prose, including quoted UI labels read by a human (`click "Learn"`) β€” never a value the reader is meant to type or paste. +- **Ellipsis**: use the single `…` character in narrative prose. Exception β€” when quoting an app's literal UI string that itself ends in three dots (`"File > Connection Setup..."`, `"My Profile..."`), reproduce it exactly; don't "correct" a real menu label. + ## Units We use the following abbreviations: From 7e7b83f9548d831d9b962128529895c047b2e195 Mon Sep 17 00:00:00 2001 From: jrd Date: Thu, 23 Jul 2026 19:40:43 +0000 Subject: [PATCH 3/6] Clarify release vs next-release targeting is case-by-case Per ann0see's review comment on #1157: there's no reliable file-type rule for branch targeting. release publishes immediately and is auto-merged into next-release by CI (.github/workflows/main.yml); next-release only ships at the next release cutover. Point agents at checking recent PR precedent instead of a false-confidence heuristic, and default to the cheaper-to-correct branch when still unsure. --- AGENTS.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index 78edb387f..6e5648114 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -15,5 +15,7 @@ Docs: [README.md](README.md) (workflow, translation process, branch targeting), ## Submit -- Target `next-release` if the change needs translation, `release` if not (README's workflow section explains which). +- Branch targeting is genuinely case by case (maintainers' own assessment) β€” there's no reliable rule like "translated content β†’ next-release." Mechanically: a merge to `release` publishes to production immediately and is auto-merged forward into `next-release` (see `.github/workflows/main.yml`); `next-release` only reaches production later, when a maintainer opens a release PR and squashes it into `release`. So the real question is "should this go live right now, or wait for the next release cutover?", not what kind of file you touched β€” `contribute/en/` and `_posts/` changes have gone directly to `release` in some PRs and to `next-release` in others. +- Before opening the PR, check recent precedent for files like the ones you're touching, e.g. `gh pr list --repo jamulussoftware/jamuluswebsite --base release --state merged --limit 30 --json title,files` and the same with `--base next-release`. If you still can't tell, say so explicitly in the PR description and let a maintainer redirect it rather than guessing silently. +- When truly unsure and precedent doesn't settle it, default to `next-release` β€” an off-base call there is cheap to correct before it ever goes live, unlike one on `release`. - Fill out the PR template checklist. From 0f1669c65c5f95c08577bc02d9040aaa2111557a Mon Sep 17 00:00:00 2001 From: jrd Date: Sat, 25 Jul 2026 18:31:52 +0000 Subject: [PATCH 4/6] Make AGENTS.md lean and documentation-focused Rewrite AGENTS.md around the idea that documentation is not code: the bar for a change is whether it is better than what is there now, and doc fixes ship on their own schedule rather than waiting on code work. Trim to the rules an agent cannot infer: English-source-only editing, ASCII in machine-parsed contexts, British spelling, and how to choose a branch. Voice, terminology and capitalisation are left to the Style and Tone guide rather than restated here, so there is one source of truth for each. Drop the Style-and-Tone punctuation section from this PR for now; a shorter replacement scoped to machine-parsed contexts is in progress. Written in plain ASCII throughout. Co-Authored-By: Claude Opus 5 --- AGENTS.md | 27 +++++++++++++++------------ contribute/en/Style-and-Tone.md | 15 --------------- 2 files changed, 15 insertions(+), 27 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 6e5648114..7db035dd5 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,21 +1,24 @@ -# Jamulus Website β€” Agent Instructions +# Jamulus Website - Agent Instructions -Content repo for jamulus.io (wiki/docs). English is the source of truth β€” edits land in English first, then flow to other languages via Weblate/po4a. +Content repo for jamulus.io. English is the source of truth: edits land in English first, then flow to other languages via Weblate/po4a. -Docs: [README.md](README.md) (workflow, translation process, branch targeting), [Style and Tone guide](https://jamulus.io/contribute/Style-and-Tone) (voice, terminology, capitalisation β€” applies to agents without exception). +Read first: [README.md](README.md) (workflow, translation, branches) and the [Style and Tone guide](https://jamulus.io/contribute/Style-and-Tone) (voice, terminology, spelling). The guide governs; this file does not restate or override it. + +## Changes + +This is documentation, not code. The bar is: **is this better than what is there now?** Not complete, not final - better. A page that answers a reader's question one step sooner is worth submitting on its own. + +- One logical improvement per PR. Open several small PRs rather than one large one, and keep each reviewable. +- Never hold a documentation fix behind a code change. Pages ship on their own schedule. +- If you cannot tell whether your version is better, say so in the PR description instead of guessing. ## Rules -- Smallest possible PRs: one logical change each. -- Edit English source `.md` files only β€” never hand-edit translated-language files or `.po` files; those belong to translators via Weblate. -- **Punctuation**: follow the Punctuation section in Style-and-Tone.md (dash/hyphen choice, curly vs. straight quotes, ellipsis). Word/Google Docs autocorrect and some LLM output insert curly characters by default even inside code β€” before opening a PR, check your diff specifically for stray curly quotes/dashes near any code span, CLI example, or other machine-parsed value. -- Prefer hedged phrasing over absolute claims where the claim isn't a hard limit (e.g. "discouraged" over "not recommended", "up to N" over "less than N") β€” follows the guide's "give solutions first, avoid overly stylised language" principle. +- Edit English source `.md` files only. Never hand-edit translated files or `.po` files - those belong to translators via Weblate. +- Plain ASCII (`-` `'` `"`) inside anything parsed or copy-pasted: code, CLI flags, URLs, frontmatter, dates, versions. Autocorrect and LLM output break this by default; check your diff. - British English spelling (colour, minimise, centre). -- Match established terminology exactly: Server/Client (capitalised = a Jamulus app instance) vs. server/client (lowercase = the physical/cloud machine); "person" not "musician"; "sound card" vs. "audio interface" β€” full list in Style-and-Tone.md. -## Submit +## Submitting -- Branch targeting is genuinely case by case (maintainers' own assessment) β€” there's no reliable rule like "translated content β†’ next-release." Mechanically: a merge to `release` publishes to production immediately and is auto-merged forward into `next-release` (see `.github/workflows/main.yml`); `next-release` only reaches production later, when a maintainer opens a release PR and squashes it into `release`. So the real question is "should this go live right now, or wait for the next release cutover?", not what kind of file you touched β€” `contribute/en/` and `_posts/` changes have gone directly to `release` in some PRs and to `next-release` in others. -- Before opening the PR, check recent precedent for files like the ones you're touching, e.g. `gh pr list --repo jamulussoftware/jamuluswebsite --base release --state merged --limit 30 --json title,files` and the same with `--base next-release`. If you still can't tell, say so explicitly in the PR description and let a maintainer redirect it rather than guessing silently. -- When truly unsure and precedent doesn't settle it, default to `next-release` β€” an off-base call there is cheap to correct before it ever goes live, unlike one on `release`. +- Branch: `release` publishes immediately and merges forward; `next-release` waits for the next release cutover. Ask "should this be live now?", not "what file did I touch?". Check precedent for similar files in recent merged PRs. If unsure, use `next-release` - a wrong call there is cheap to correct. - Fill out the PR template checklist. diff --git a/contribute/en/Style-and-Tone.md b/contribute/en/Style-and-Tone.md index ac4bf0526..197d2d6b6 100644 --- a/contribute/en/Style-and-Tone.md +++ b/contribute/en/Style-and-Tone.md @@ -101,21 +101,6 @@ Jamulus is "Free and Open Source (FOSS)" (not "free software" or "open source") "Server List" This is the list of Servers maintained by a Directory. A Server registers with a Directory to be _listed_ in that Directory’s _server list_. -## Punctuation - -One governing question for every dash, quote, or ellipsis: is this character doing a job a parser depends on, or is it doing prose work for a human reader? Machine-context wins every time; only prose gets the fancier character. - -Never use a curly/typographic character inside a code span or fenced code block, an HTML attribute, YAML frontmatter, a CLI flag, a Markdown list/checkbox bullet, an ISO 8601 date (`2021-03-17`), a version/build string (`3.7.0dev-123456`), a URL, or anything meant to be copied and pasted verbatim (a shell command, a JSON snippet, a config value). In all of these, a smart quote, em-dash, or en-dash is either a parser error or a silent corruption of a value the reader will paste elsewhere. Plain ASCII `-`, `'`, `"` only. - -Everywhere else β€” prose meant to be read, not executed β€” use the correct typographic character: - -- **Hyphen (`-`)**: compound modifiers only (`low-bandwidth`, `text-wrapping`). If you can mentally replace it with "to" or read it as a parenthetical break, it isn't a hyphen's job. -- **En dash (`–`), no surrounding spaces**: numeric ranges (`0–16`, `30–50 ms`, `pages 16–18`). -- **En dash (`–`), with spaces**: a "Title – Subtitle" page title, matching the existing pattern in `Command-Line-Options.md`, `Privacy-Statement.md`, and `2020-03-28-Server-Rpi.md`. -- **Em dash (`β€”`), with spaces on both sides**: a parenthetical aside, appositive, or sentence interruption β€” matches the site's own pre-existing usage (`misc/1-index.md`). Never use a doubled hyphen (`--`) as a substitute; it's a typewriter-era workaround, not a typographic period. -- **Curly quotes/apostrophes (`’ β€œ ”`)**: prose, including quoted UI labels read by a human (`click "Learn"`) β€” never a value the reader is meant to type or paste. -- **Ellipsis**: use the single `…` character in narrative prose. Exception β€” when quoting an app's literal UI string that itself ends in three dots (`"File > Connection Setup..."`, `"My Profile..."`), reproduce it exactly; don't "correct" a real menu label. - ## Units We use the following abbreviations: From 9420693368a9b158cd77ef98a7d08a0f07d881f8 Mon Sep 17 00:00:00 2001 From: jrd Date: Sat, 25 Jul 2026 18:42:00 +0000 Subject: [PATCH 5/6] Style and Tone: add a Punctuation section, and state that it covers agents Adds the rule that actually has a failure mode: plain ASCII inside anything parsed or copied - code spans, CLI flags, URLs, frontmatter, dates, versions - where a curly quote or long dash silently corrupts a value the reader pastes elsewhere. In prose, ASCII is described as the safe default that most pages already use, without prohibiting typographic characters or requiring anyone to convert existing pages. This documents what the English source already does: of 27 files in wiki/en and contribute/en, none contains a curly character inside a code span, while 8 use curly quotes in prose - including this guide. Also states in the introduction that these guidelines cover AI-assisted contributions, which is what lets AGENTS.md point here instead of restating voice, terminology and spelling. AGENTS.md regains its pointer to the new section. Co-Authored-By: Claude Opus 5 --- AGENTS.md | 2 +- contribute/en/Style-and-Tone.md | 12 ++++++++++++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index 7db035dd5..d537c14ed 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -15,7 +15,7 @@ This is documentation, not code. The bar is: **is this better than what is there ## Rules - Edit English source `.md` files only. Never hand-edit translated files or `.po` files - those belong to translators via Weblate. -- Plain ASCII (`-` `'` `"`) inside anything parsed or copy-pasted: code, CLI flags, URLs, frontmatter, dates, versions. Autocorrect and LLM output break this by default; check your diff. +- Plain ASCII (`-` `'` `"`) inside anything parsed or copy-pasted: code, CLI flags, URLs, frontmatter, dates, versions. Autocorrect and LLM output break this by default; check your diff. See the Punctuation section of the Style and Tone guide. - British English spelling (colour, minimise, centre). ## Submitting diff --git a/contribute/en/Style-and-Tone.md b/contribute/en/Style-and-Tone.md index 197d2d6b6..5ac634e93 100644 --- a/contribute/en/Style-and-Tone.md +++ b/contribute/en/Style-and-Tone.md @@ -10,6 +10,8 @@ permalink: "/contribute/Style-and-Tone" While contributing to Jamulus or the website, you should also keep style and tone in mind. Have a look at the following guidelines. +These guidelines apply to every contribution, including work drafted with AI assistance. The `AGENTS.md` file in the website repository points automated contributors here rather than repeating them, so this page stays the single source of truth. + **Note:** It is very important to thoroughly proofread content before submitting it, as any corrections made later have a knock-on effect on translations.
@@ -101,6 +103,16 @@ Jamulus is "Free and Open Source (FOSS)" (not "free software" or "open source") "Server List" This is the list of Servers maintained by a Directory. A Server registers with a Directory to be _listed_ in that Directory’s _server list_. +## Punctuation + +Content here is written for people, but parts of it are read by tools as well. Keep the two apart. + +Inside anything a reader will copy or a tool will parse - code spans and fenced blocks, command-line flags, URLs, file paths, YAML frontmatter, HTML attributes, dates and version strings - use plain ASCII `-`, `'` and `"` only. A curly quote or a long dash pasted into a shell command, a config file or a search box is not the character the tool expects, and it fails in ways the reader cannot see. Word processors and AI writing tools insert those characters automatically, so check your work before submitting. + +In prose, plain ASCII is the safe default and most pages already use it. Where a typographic character genuinely helps the reader it is acceptable, but it is never required. Do not convert a page from one style to the other as a change of its own: that produces a large diff with no benefit to the reader, and churn for translators. + +When quoting a literal label from the app, reproduce it exactly, including any trailing dots ("File > Connection Setup..."). Do not correct a real menu label. + ## Units We use the following abbreviations: From b25006cca10bedb93e42b5c5a20d00d75dc6ad1d Mon Sep 17 00:00:00 2001 From: jrd Date: Sat, 25 Jul 2026 18:46:34 +0000 Subject: [PATCH 6/6] AGENTS.md: make branch choice a rule instead of a judgement call The previous wording asked whether a change should be live now, which invites an agent to reason about urgency. Merge history says the determinant is translation, not urgency: across the last 60 merged PRs (#1039-#1160), all 15 touching wiki/ went to next-release and none went to release, while all 6 touching _posts/ went to release. wiki/ is the only tree po4a walks, so an English edit there has to wait for the translation sprint rather than appear untranslated on a live page. State that as the rule, with next-release as the default. Co-Authored-By: Claude Opus 5 --- AGENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index d537c14ed..094513361 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -20,5 +20,5 @@ This is documentation, not code. The bar is: **is this better than what is there ## Submitting -- Branch: `release` publishes immediately and merges forward; `next-release` waits for the next release cutover. Ask "should this be live now?", not "what file did I touch?". Check precedent for similar files in recent merged PRs. If unsure, use `next-release` - a wrong call there is cheap to correct. +- Branch: `next-release` unless you have a reason. `release` is the live site and publishes immediately; `next-release` waits for the next release cutover. Anything under `wiki/` must go to `next-release` - it is the only tree that gets translated, and it has to wait for the translation sprint. Blog posts under `_posts/` and urgent build fixes go to `release`. - Fill out the PR template checklist.